Upstream Android JNI code, allowing us to use more ScopedJava references.

Upstream Android JNI code, allowing us to use more ScopedJava references.

BUG=
TEST=


Committed: http://src.chromium.org/viewvc/chrome?view=rev&revision=121284

[Peter Beverloo, 2012-02-08 16:47:57]

This includes the changes in Satish' CL here:
http://codereview.chromium.org/9358001/

Full patch (including file changes) can be found downstream on the following
url, currently upstreamed files using the old (non-scoped) approach will be
updated in subsequent CLs.
https://gerrit-int.chromium.org/#change,10917

[joth, 2012-02-08 18:28:31]

https://chromiumcodereview.appspot.com/9358028/diff/1/base/android/jni_android.h
File base/android/jni_android.h (right):

https://chromiumcodereview.appspot.com/9358028/diff/1/base/android/jni_androi...
base/android/jni_android.h:90: const JavaRef<jclass>& clazz,
odd to pass an explicit env when we could use clazz.env() instead.
Is this for thread correctness?

[Steve Block, 2012-02-08 18:41:55]

https://chromiumcodereview.appspot.com/9358028/diff/1/base/android/jni_android.h
File base/android/jni_android.h (right):

https://chromiumcodereview.appspot.com/9358028/diff/1/base/android/jni_androi...
base/android/jni_android.h:90: const JavaRef<jclass>& clazz,
I think this was an oversight in the original review. I can't think of a case
where these methods are used with an JNIEnv from a different thread to that of
the clazz.

https://chromiumcodereview.appspot.com/9358028/diff/1/base/android/jni_string.h
File base/android/jni_string.h (right):

https://chromiumcodereview.appspot.com/9358028/diff/1/base/android/jni_string...
base/android/jni_string.h:23: ScopedJavaLocalRef<jstring>
ConvertUTF8ToJavaString(
I think this will break JavaBoundObject. Is the Java Bridge currently compiled
in an upstream Android build? If not, it would be good to fix that ASAP, as it's
not built on any other upstream platforms.

[Jay Civelli, 2012-02-08 18:49:56]

https://chromiumcodereview.appspot.com/9358028/diff/1/base/android/jni_android.h
File base/android/jni_android.h (right):

https://chromiumcodereview.appspot.com/9358028/diff/1/base/android/jni_androi...
base/android/jni_android.h:90: const JavaRef<jclass>& clazz,
On 2012/02/08 18:41:55, Steve Block wrote:
> I think this was an oversight in the original review. I can't think of a case
> where these methods are used with an JNIEnv from a different thread to that of
> the clazz.
I believe there were actually some tests running into that scenario somehow.
Some code might create a global ref to a class in one thread, and then try to
get fields or methods later on from another one.

https://chromiumcodereview.appspot.com/9358028/diff/1/base/android/jni_string.h
File base/android/jni_string.h (right):

https://chromiumcodereview.appspot.com/9358028/diff/1/base/android/jni_string...
base/android/jni_string.h:23: ScopedJavaLocalRef<jstring>
ConvertUTF8ToJavaString(
On 2012/02/08 18:41:55, Steve Block wrote:
> I think this will break JavaBoundObject. Is the Java Bridge currently compiled
> in an upstream Android build? If not, it would be good to fix that ASAP, as
it's
> not built on any other upstream platforms.
In the JavaBoundObject we release the actual scoped pointer so the behavior
should be the same as it was before.

[Steve Block, 2012-02-08 19:02:43]

https://chromiumcodereview.appspot.com/9358028/diff/1/base/android/jni_android.h
File base/android/jni_android.h (right):

https://chromiumcodereview.appspot.com/9358028/diff/1/base/android/jni_androi...
base/android/jni_android.h:90: const JavaRef<jclass>& clazz,
Hmm, if we want to support that use-case, we should add a comment to make it
very clear that env must be valid for the calling thread, but that clazz.env()
need not be.

However, in general, this seems like it could lead to confusion. I wonder if
it's better to remove the env param here, and the minority of call sites that
need this edge-case behaviour can call JNI methods directly. This could be a
TODO for the purposes of this patch.

https://chromiumcodereview.appspot.com/9358028/diff/1/base/android/jni_string.h
File base/android/jni_string.h (right):

https://chromiumcodereview.appspot.com/9358028/diff/1/base/android/jni_string...
base/android/jni_string.h:23: ScopedJavaLocalRef<jstring>
ConvertUTF8ToJavaString(
I just meant that it will cause a build break. JavaBoundObject uses 'jobject foo
= ConvertUTF8ToJavaString(...);'

[Jay Civelli, 2012-02-08 19:20:47]

https://chromiumcodereview.appspot.com/9358028/diff/1/base/android/jni_android.h
File base/android/jni_android.h (right):

https://chromiumcodereview.appspot.com/9358028/diff/1/base/android/jni_androi...
base/android/jni_android.h:90: const JavaRef<jclass>& clazz,
On 2012/02/08 19:02:43, Steve Block wrote:
> Hmm, if we want to support that use-case, we should add a comment to make it
> very clear that env must be valid for the calling thread, but that clazz.env()
> need not be.
> 
> However, in general, this seems like it could lead to confusion. I wonder if
> it's better to remove the env param here, and the minority of call sites that
> need this edge-case behaviour can call JNI methods directly. This could be a
> TODO for the purposes of this patch.
Yeah, I dislike that case as well.
My main concern is that that contract is hard to enforce (that the
HasMethod/GetMethod methods are called on the same thread the class was
retrieved).
Someone could change some code and not realize that they are now breaking the
contract.
Passing the JNIEnv makes it less error prone in that way.

[joth, 2012-02-08 19:52:09]

On 8 February 2012 19:20, <[email protected]> wrote:

>
> https://chromiumcodereview.**appspot.com/9358028/diff/1/**
>
base/android/jni_android.h<https://chromiumcodereview.appspot.com/9358028/diff/1/base/android/jni_android.h>
> File base/android/jni_android.h (right):
>
> https://chromiumcodereview.**appspot.com/9358028/diff/1/**
>
base/android/jni_android.h#**newcode90<https://chromiumcodereview.appspot.com/9358028/diff/1/base/android/jni_android.h#newcode90>
> base/android/jni_android.h:90: const JavaRef<jclass>& clazz,
> On 2012/02/08 19:02:43, Steve Block wrote:
>
>> Hmm, if we want to support that use-case, we should add a comment to
>>
> make it
>
>> very clear that env must be valid for the calling thread, but that
>>
> clazz.env()
>
>> need not be.
>>
>
>  However, in general, this seems like it could lead to confusion. I
>>
> wonder if
>
>> it's better to remove the env param here, and the minority of call
>>
> sites that
>
>> need this edge-case behaviour can call JNI methods directly. This
>>
> could be a
>
>> TODO for the purposes of this patch.
>>
> Yeah, I dislike that case as well.
> My main concern is that that contract is hard to enforce (that the
> HasMethod/GetMethod methods are called on the same thread the class was
> retrieved).
> Someone could change some code and not realize that they are now
> breaking the contract.
> Passing the JNIEnv makes it less error prone in that way.
>
>
Yep my inclination is to leave it as is for this patch, and make a TODO to
address later. I'm starting to get convinced holding onto the env inside a
global ref is a bad idea, as it's too easy in the general case that the
d'tor or some other usage will happen on a different thread (this was also
the problem we had with GetApplicationContext returning a ref). This will
mean removing env() from the base class...

[Peter Beverloo, 2012-02-09 15:25:29]

Added a TODO (Jay, please verify) and replied to the other comments. Also
rebased following Satish'
http://src.chromium.org/viewvc/chrome?view=rev&revision=121093

https://chromiumcodereview.appspot.com/9358028/diff/1/base/android/jni_android.h
File base/android/jni_android.h (right):

https://chromiumcodereview.appspot.com/9358028/diff/1/base/android/jni_androi...
base/android/jni_android.h:90: const JavaRef<jclass>& clazz,
On 2012/02/08 19:20:47, Jay Civelli wrote:
> On 2012/02/08 19:02:43, Steve Block wrote:
> > Hmm, if we want to support that use-case, we should add a comment to make it
> > very clear that env must be valid for the calling thread, but that
clazz.env()
> > need not be.
> > 
> > However, in general, this seems like it could lead to confusion. I wonder if
> > it's better to remove the env param here, and the minority of call sites
that
> > need this edge-case behaviour can call JNI methods directly. This could be a
> > TODO for the purposes of this patch.
> Yeah, I dislike that case as well.
> My main concern is that that contract is hard to enforce (that the
> HasMethod/GetMethod methods are called on the same thread the class was
> retrieved).
> Someone could change some code and not realize that they are now breaking the
> contract.
> Passing the JNIEnv makes it less error prone in that way. 

I added a TODO as Steve suggested, and attributed it to Jay. Jay, does this work
for you?

https://chromiumcodereview.appspot.com/9358028/diff/1/base/android/jni_string.h
File base/android/jni_string.h (right):

https://chromiumcodereview.appspot.com/9358028/diff/1/base/android/jni_string...
base/android/jni_string.h:23: ScopedJavaLocalRef<jstring>
ConvertUTF8ToJavaString(
On 2012/02/08 19:02:43, Steve Block wrote:
> I just meant that it will cause a build break. JavaBoundObject uses 'jobject
foo
> = ConvertUTF8ToJavaString(...);'

There are several other files which have to be updated, I'll do that in follow
up CLs. We don't build the content/ folder at this time yet.

[Jay Civelli, 2012-02-09 18:00:04]

On 2012/02/09 15:25:29, Peter Beverloo wrote:
> Added a TODO (Jay, please verify) and replied to the other comments. 
LGTM

Also
> rebased following Satish'
> http://src.chromium.org/viewvc/chrome?view=rev&revision=121093
> 
>
https://chromiumcodereview.appspot.com/9358028/diff/1/base/android/jni_android.h
> File base/android/jni_android.h (right):
> 
>
https://chromiumcodereview.appspot.com/9358028/diff/1/base/android/jni_androi...
> base/android/jni_android.h:90: const JavaRef<jclass>& clazz,
> On 2012/02/08 19:20:47, Jay Civelli wrote:
> > On 2012/02/08 19:02:43, Steve Block wrote:
> > > Hmm, if we want to support that use-case, we should add a comment to make
it
> > > very clear that env must be valid for the calling thread, but that
> clazz.env()
> > > need not be.
> > > 
> > > However, in general, this seems like it could lead to confusion. I wonder
if
> > > it's better to remove the env param here, and the minority of call sites
> that
> > > need this edge-case behaviour can call JNI methods directly. This could be
a
> > > TODO for the purposes of this patch.
> > Yeah, I dislike that case as well.
> > My main concern is that that contract is hard to enforce (that the
> > HasMethod/GetMethod methods are called on the same thread the class was
> > retrieved).
> > Someone could change some code and not realize that they are now breaking
the
> > contract.
> > Passing the JNIEnv makes it less error prone in that way. 
> 
> I added a TODO as Steve suggested, and attributed it to Jay. Jay, does this
work
> for you?
> 
>
https://chromiumcodereview.appspot.com/9358028/diff/1/base/android/jni_string.h
> File base/android/jni_string.h (right):
> 
>
https://chromiumcodereview.appspot.com/9358028/diff/1/base/android/jni_string...
> base/android/jni_string.h:23: ScopedJavaLocalRef<jstring>
> ConvertUTF8ToJavaString(
> On 2012/02/08 19:02:43, Steve Block wrote:
> > I just meant that it will cause a build break. JavaBoundObject uses 'jobject
> foo
> > = ConvertUTF8ToJavaString(...);'
> 
> There are several other files which have to be updated, I'll do that in follow
> up CLs. We don't build the content/ folder at this time yet.

[brettw, 2012-02-09 18:06:53]

Base owners rubberstamp LGTM based on Jay's review.

[joth, 2012-02-09 18:15:45]

lgtm

[commit-bot: I haz the power, 2012-02-09 18:19:02]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/[email protected]/9358028/6001

[commit-bot: I haz the power, 2012-02-09 21:02:32]

Change committed as 121284