Closed Bug 1049105 Opened 11 years ago Closed 11 years ago

Remove generateStatic parameter for WrapElementForJNI annotation

Categories

(Core Graveyard :: Widget: Android, defect)

All
Android
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
mozilla34

People

(Reporter: kats, Assigned: ckitching)

Details

Attachments

(3 files, 1 obsolete file)

Having the generateStatic = true such as at [1] seems redundant. The function is already static and the codegen tool that uses the annotation already produces a static wrapper based on the function's static-ness [2]. If the two pieces of information conflict then the codegen tool will generate a static wrapper for a non-static function but it's not clear what will happen if anybody attempts to call it. [1] http://mxr.mozilla.org/mozilla-central/source/mobile/android/base/GeckoAppShell.java?rev=4cbef502c1dc#455 [2] http://mxr.mozilla.org/mozilla-central/source/build/annotationProcessors/CodeGenerator.java?rev=8fac243930da#100
I think this is left over from the first revision of the code generator that didn't generate a C++ class for each wrapped class, but instead was generating wrappers in a single, large class. This option could still be meaningfully used: should you want a static C++ method that corresponds to a non-static Java method. Since JNI wrapper methods take the Java instance as a parameter, that (I think) would still work. It'd just be a really stupid thing to do. This option, then, is mostly a footgun, and one that doesn't provide a particularly useful feature. Let's get rid of it.
Assignee: nobody → chriskitching
That became quite the cleanup patch, and didn't change the generated code at all, so looks like victory. Well spotted!
Attachment #8468097 - Flags: review?(bugmail.mozilla)
Attachment #8468097 - Attachment is obsolete: true
Attachment #8468097 - Flags: review?(bugmail.mozilla)
And I just remembered I had this patch lying around in one of my queues: makes it impossible to put the annotations on element types where they make no sense. Will help IDE users avoid unfortunate compile errors (and give others a less confusing one than <evil annotation processor stacktrace>) Might be worth having, too?
Attachment #8468123 - Flags: review?(bugmail.mozilla)
Also found this one lying around: makes the annotation processor have no warnings with linting turned on (which I think I wrote as part of my work to make everything compile with JDK 8, since more warnings are on by default on that compiler).
Attachment #8468134 - Flags: review?(bugmail.mozilla)
Comment on attachment 8468098 [details] [diff] [review] V2: Remove generateStatic option from JNI wrapper generator Review of attachment 8468098 [details] [diff] [review]: ----------------------------------------------------------------- ::: build/annotationProcessors/CodeGenerator.java @@ +408,5 @@ > } > > /** > * Generates the method body of the C++ wrapper function for the Java method indicated. > + * trailing ws ::: mobile/android/base/GeckoAppShell.java @@ +451,5 @@ > reportJavaCrash(getStackTraceString(e)); > } > } > > + @WrapElementForJNI() Remove parens, here and in the next two below as well.
Attachment #8468098 - Flags: review?(bugmail.mozilla) → review+
Attachment #8468123 - Flags: review?(bugmail.mozilla) → review+
Comment on attachment 8468134 [details] [diff] [review] Make annotation processor compile with Xlint:all Review of attachment 8468134 [details] [diff] [review]: ----------------------------------------------------------------- Mostly rubber-stamping this (and the previous patch). As long as it generates the same code and compiles on platforms people are using I'm fine with it.
Attachment #8468134 - Flags: review?(bugmail.mozilla) → review+
QA Whiteboard: [qa-]
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: