Closed Bug 1186530 Opened 9 years ago Closed 9 years ago

Implement per-instance forwarding of native Java methods

Categories

(Firefox for Android Graveyard :: General, defect)

All
Android
defect
Not set
normal

Tracking

(firefox42 fixed)

RESOLVED FIXED
Firefox 42
Tracking Status
firefox42 --- fixed

People

(Reporter: jchen, Assigned: jchen)

References

Details

Attachments

(2 files, 1 obsolete file)

Bug 1178850 added a new framework to implement native methods. This bug will add support for instance native methods: native calls on a Java object will automatically be forwarded to calls on a C++ object that corresponds to the Java instance.
Introduce a JNIObject class that serves as a base class for classes that wish to use per-instance native methods. JNIObject includes a long native pointer field that the C++ code accesses to associate the Java object instance with a C++ object instance.
Attachment #8639506 - Flags: review?(snorp)
We use Ref::From() inside TypeAdapter<Ref>::ToNative to convert a raw JNI ref argument to a Ref argument for the C++ function. However, that generates a compile error, unless we make TypeAdapter<Ref> a friend of Ref, because we intentionally made Ref's copy constructor private and returning from TypeAdapter<Ref>::ToNative requires the copy constructor.
Attachment #8639507 - Flags: review?(snorp)
Comment on attachment 8639506 [details] [diff] [review] Add support for instance native pointers; Review of attachment 8639506 [details] [diff] [review]: ----------------------------------------------------------------- I think we want JNIObject to be an interface, that way we don't have to force an hierarchy that may not be possible (LayerView, for instance). You could add an AbstractJNIObject to implement it for simpler cases. ::: mobile/android/base/mozglue/JNIObject.java @@ +6,5 @@ > + // Pointer to a WeakPtr object that refers to the native object. > + private long mHandle; > + > + // Dispose of any reference to a native object. > + protected abstract void dispose(); I think this could easily conflict with other methods in the subclasses. I recommend something more specific. disposeNativeHandle() maybe?
Attachment #8639506 - Flags: review?(snorp) → review-
Attachment #8639507 - Flags: review?(snorp) → review+
(In reply to James Willcox (:snorp) (jwillcox@mozilla.com) from comment #3) > Comment on attachment 8639506 [details] [diff] [review] > Add support for instance native pointers; > > Review of attachment 8639506 [details] [diff] [review]: > ----------------------------------------------------------------- > > I think we want JNIObject to be an interface, that way we don't have to > force an hierarchy that may not be possible (LayerView, for instance). You > could add an AbstractJNIObject to implement it for simpler cases. Discussed in 1:1 that classes like LayerView would use an inner class, which inherits from JNIObject, to implement instance native methods. Having JNIObject being an abstract class makes things on the C++ side a lot easier. > ::: mobile/android/base/mozglue/JNIObject.java > @@ +6,5 @@ > > + // Pointer to a WeakPtr object that refers to the native object. > > + private long mHandle; > > + > > + // Dispose of any reference to a native object. > > + protected abstract void dispose(); > > I think this could easily conflict with other methods in the subclasses. I > recommend something more specific. disposeNativeHandle() maybe? Okay, disposeNative()?
Attachment #8639506 - Attachment is obsolete: true
Attachment #8640173 - Flags: review?(snorp)
Comment on attachment 8640173 [details] [diff] [review] Add support for instance native pointers (v2) Review of attachment 8640173 [details] [diff] [review]: ----------------------------------------------------------------- After discussing on Vidyo, Jim convinced me that the abstract class is alright.
Attachment #8640173 - Flags: review?(snorp) → review+
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: