New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 842329 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner:
Closed: Jun 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Android
Pri: 3
Type: Bug



Sign in to add a comment

Let all BoundaryInterfaces inherit from a common type

Project Member Reported by ntfschr@chromium.org, May 11 2018

Issue description

Gustav proposed this in  http://crbug.com/842022#c1 .

> It might be useful to ensure that objects passed to BoundaryInterfaceReflectionUtil.createInvocationHandlerFor() are indeed BoundaryInterfaces. Or maybe we should just create an interface/class called BoundaryInterface and have all BoundaryInterfaces inherit from that (and define BoundaryInterfaceReflectionUtil.createInvocationHandlerFor(BoundaryInterface)).
 
This *almost* works. After the code change (demo CL: http://crrev/c/1056142), I get one compile error:

../../android_webview/support_library/callback/java/src/org/chromium/support_lib_callback_glue/SupportLibWebViewContentsClientAdapter.java:58: error: incompatible types: WebViewClient cannot be converted to BoundaryInterface
                BoundaryInterfaceReflectionUtil.createInvocationHandlerFor(possiblyCompatClient);

This makes sense: possiblyCompatClient is a WebViewClient. At this point in the code, we know it's a WebViewClientCompat (and therefore inherits the corresponding BoundaryInterface). However, it's a WebViewClientCompat defined in the *other* ClassLoader, and therefore is not considered to be a BoundaryInterface as defined in *this* ClassLoader.

I don't know if there's a way around this--even if we do trickery to cast this to a BoundaryInterface[app ClassLoader], it still won't be considered a BoundaryInterface[chromium ClassLoader].

I have not yet attempted cherry picking this change to the support library side, so that may also pose issues.
Status: WontFix (was: Assigned)
I'm going to close this for now, due to the compile error mentioned in comment 1. I don't think this error is unsolvable, but I think any solution would overly complicating the code, outweighing potential benefit.

Sign in to add a comment