Bug 31847 - Interfaces that inherit from IJavaObject cause "cannot find symbol" during Java compilation if used as parameter types in constructors for classes that generate ACWs
Summary: Interfaces that inherit from IJavaObject cause "cannot find symbol" during Ja...
Status: CONFIRMED
Alias: None
Product: Android
Classification: Xamarin
Component: General (show other bugs)
Version: 5.1
Hardware: PC All
: Normal normal
Target Milestone: master
Assignee: Jonathan Pryor
URL:
Depends on:
Blocks:
 
Reported: 2015-07-10 22:29 UTC by Brendan Zagaeski (Xamarin Support)
Modified: 2015-08-01 08:57 UTC (History)
3 users (show)

See Also:
Tags:
Is this bug a regression?: ---
Last known good build:


Attachments
Test case (30.51 KB, application/zip)
2015-07-10 22:29 UTC, Brendan Zagaeski (Xamarin Support)
Details
Diagnostic build output and version info (15.37 KB, application/zip)
2015-07-10 22:29 UTC, Brendan Zagaeski (Xamarin Support)
Details

Description Brendan Zagaeski (Xamarin Support) 2015-07-10 22:29:11 UTC
Created attachment 11986 [details]
Test case

Interfaces that inherit from IJavaObject cause "cannot find symbol" during Java compilation if used as parameter types in constructors for classes that generate Android Callable Wrappers.


I think constructors are a special case because they don't use the `override` keyword. For other methods, the only way they can appear in the ACW is if they override _existing_ methods from ancestor classes.



I can imagine at least two different possibilities for what might be "correct" for this bug:


a. Users should avoid using any interfaces that inherit from `IJavaObject` as parameter types in constructors for classes that generate ACWs unless those interfaces are in fact _bindings_ to underlying Java interfaces (as is the case with `IAdapter`, for example).


b. The ACW generation mechanism should skip these "bad" constructors somehow. I think that would allow users to add and call this type of constructor on the C# side of the program without any errors.




## Regression status: probably not a regression

The behavior is the same on Xamarin.Android 4.12.1 and Xamarin.Android 5.1.4.




## Steps to reproduce

Attempt to build the attached test case. The test case is just a new template Android app plus the following few lines:

> public interface IInterface1 : IJavaObject
> {
> }
> 
> public class Class1 : Java.Lang.Object
> {
>     public Class1(IInterface1 source)
>     {
>     }
> }




## Results

The build fails during Java compilation:

> obj/Debug/android/src/md5c178831cd46fc53bebc42cf953f78ced/Class1.java(24,52): error :  error: cannot find symbol
> 	public Class1 (md5c178831cd46fc53bebc42cf953f78ced.IInterface1 p0) throws java.lang.Throwable
>   symbol:   class IInterface1
>   location: package md5c178831cd46fc53bebc42cf953f78ced


### Problematic constructor from `Class1.java`

> public Class1 (md5c178831cd46fc53bebc42cf953f78ced.IInterface1 p0) throws java.lang.Throwable
> {
> 	super ();
> 	if (getClass () == Class1.class)
> 		mono.android.TypeManager.Activate ("AndroidApp1.Class1, AndroidApp1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null", "AndroidApp1.IInterface1, AndroidApp1, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null", this, new java.lang.Object[] { p0 });
> }
Comment 1 Brendan Zagaeski (Xamarin Support) 2015-07-10 22:29:39 UTC
Created attachment 11987 [details]
Diagnostic build output and version info
Comment 2 Jonathan Pryor 2015-07-11 09:21:19 UTC
We do not currently support interfaces inheriting from IJavaObject, though it is something we'd like to investigate.

Furthermore, this isn't something that we can easily check for -- if a type implements IJavaObject, we assume that a corresponding Java peer will exist "somehow" (via .jar or because we generate it); there's no way to ask "is this type implementing IJavaObject actually valid?", particularly if it's an interface type.

So even checking for this for warning purposes isn't possible.

Don't Do That™.
Comment 4 Udham Singh 2015-07-13 06:04:28 UTC
I have checked this issue with the help of test case attached in bug description and able to reproduce the reported behaviour. Please refer the screencast : http://www.screencast.com/t/Scm9oZZtzQyd

Build Output : https://gist.github.com/Udham1/b2c7c80b6cb4ecc78add
Ide Log : https://gist.github.com/Udham1/9014e20f4857390cea2a
Error Log : https://gist.github.com/Udham1/dcbde55a74b527c3ccb6

Environment Info : 

=== Xamarin Studio ===

Version 5.9.4 (build 5)
Installation UUID: ce927b2a-2c07-44c5-b186-09cfdafba6dc
Runtime:
	Mono 4.0.2 ((detached/c99aa0c)
	GTK+ 2.24.23 (Raleigh theme)

	Package version: 400020005

=== Apple Developer Tools ===

Xcode 6.2 (6776)
Build 6C131e

=== Xamarin.Android ===

Version: 5.1.4.16 (Enterprise Edition)
Android SDK: /Users/xamarin76/Desktop/android-sdk-macosx
	Supported Android versions:
		2.3    (API level 10)
		4.0.3  (API level 15)
		4.1    (API level 16)
		4.2    (API level 17)
		4.3    (API level 18)
		4.4    (API level 19)
		4.4.87 (API level 20)
		5.0    (API level 21)
Java SDK: /usr
java version "1.7.0_65"
Java(TM) SE Runtime Environment (build 1.7.0_65-b17)
Java HotSpot(TM) 64-Bit Server VM (build 24.65-b04, mixed mode)

=== Build Information ===

Release ID: 509040005
Git revision: 8010a90f6e246b32364e3fb46ef2c9d1be9c9a2b
Build date: 2015-06-08 16:52:06-04
Xamarin addins: 7e93e9c3503f28770f23ce1b7eafd829919f18e8

=== Operating System ===

Mac OS X 10.9.5
Darwin Xamarin76s-Mac-mini.local 13.4.0 Darwin Kernel Version 13.4.0
    Sun Aug 17 19:50:11 PDT 2014
    root:xnu-2422.115.4~1/RELEASE_X86_64 x86_64

Note You need to log in before you can comment on or make changes to this bug.