Closed Bug 1067056 Opened 5 years ago Closed 5 years ago

Remove generated JNI wrapper for DomKeyLocation

Categories

(Firefox for Android :: General, defect)

ARM
Android
defect
Not set

Tracking

()

RESOLVED FIXED
Firefox 35

People

(Reporter: ckitching, Assigned: ckitching)

References

Details

Attachments

(1 file, 1 obsolete file)

It's not used, and it's the only use of the "GeneratorOptions" annotation.

GeneratorOptions was a terrible idea: it just lets you change the name of the generated C++ class so it's different to the Java class it's wrapping. In other words, its only function is to make your code more confusing.

So, let's delete *all* the things and save a smidge of binary size (and sanity) while we're at it.
Comment on attachment 8489057 [details] [diff] [review]
Remove JavaDomKeyLocation and GeneratorOptions annotation

I'm guessing someone who's not me should review this.
Attachment #8489057 - Flags: review?(rnewman)
Attachment #8489057 - Flags: review?(nchen)
Attachment #8489057 - Flags: review?(nalexander)
Comment on attachment 8489057 [details] [diff] [review]
Remove JavaDomKeyLocation and GeneratorOptions annotation

Review of attachment 8489057 [details] [diff] [review]:
-----------------------------------------------------------------

DomKeyLocation is quite clearly used, but it does look like JavaDomKeyLocation is not.  I'd like to leave this for nchen, but f+ from me.  Always nice to remove special cases.
Attachment #8489057 - Flags: review?(nalexander) → feedback+
(In reply to Nick Alexander :nalexander from comment #3)
> DomKeyLocation is quite clearly used, but it does look like
> JavaDomKeyLocation is not.  I'd like to leave this for nchen, but f+ from
> me.  Always nice to remove special cases.

That's right: I definitely am not proposing to remove DomKeyLocation, just the C++ wrapper around it.

If we decide we want to keep the wrapper, I'd then ask to rename the C++ class to have a name matching the Java class so I can continue to get rid of @GeneratorOptions (which is the goal I really care about).
Missed a spot: It *does* still require a JNITarget annotation, for it is referred to via the JNI from code written by humans.
Attachment #8489057 - Attachment is obsolete: true
Attachment #8489057 - Flags: review?(nchen)
Attachment #8489074 - Flags: feedback?(nchen)
Comment on attachment 8489074 [details] [diff] [review]
Remove JavaDomKeyLocation and GeneratorOptions annotation

Review of attachment 8489074 [details] [diff] [review]:
-----------------------------------------------------------------

LGTM

::: mobile/android/base/GeckoEvent.java
@@ +124,1 @@
>      public enum DomKeyLocation {

We should get rid of the JNI usage. Can you file a followup to fix that?
Attachment #8489074 - Flags: feedback?(nchen) → feedback+
(In reply to Jim Chen [:jchen :nchen] from comment #6)
> We should get rid of the JNI usage. Can you file a followup to fix that?

Filed Bug 1070436.

It's unclear to me exactly how to go about this, but presumably you have an idea.

I guess the plan is to have an equivalent to the enum in C++ land and keep them synchronised? Or something?
Sounds like a job for the preprocessor, perhaps.
See Also: → 1070436
https://hg.mozilla.org/mozilla-central/rev/f2fb5159d301
Status: ASSIGNED → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 35
You need to log in before you can comment on or make changes to this bug.