1067056 - Remove generated JNI wrapper for DomKeyLocation

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Chris Kitching [:ckitching]]

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 1

[Chris Kitching [:ckitching]]

Attachment: Remove JavaDomKeyLocation and GeneratorOptions annotation

Comment 2

[Richard Newman [:rnewman]]

Comment on attachment 8489057 [details] [diff] [review]
Remove JavaDomKeyLocation and GeneratorOptions annotation

I'm guessing someone who's not me should review this.

Comment 3

[Nick Alexander :nalexander [he/him]]

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.

Comment 4

[Chris Kitching [:ckitching]]

(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).

Comment 5

[Chris Kitching [:ckitching]]

Attachment: Remove JavaDomKeyLocation and GeneratorOptions annotation

Missed a spot: It *does* still require a JNITarget annotation, for it is referred to via the JNI from code written by humans.

Comment 6

[(inactive) Jim Chen [:jchen] [:darchons]]

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?

Comment 7

[Chris Kitching [:ckitching]]

https://hg.mozilla.org/integration/fx-team/rev/f2fb5159d301

Comment 8

[Chris Kitching [:ckitching]]

(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.

Comment 9

[Tim Taubert [:ttaubert] (inactive)]

https://hg.mozilla.org/mozilla-central/rev/f2fb5159d301