Re: [Ikvm-developers] Attributes of synthesized inner interfaces

[Jeroen F. <je...@su...>]

I would argue that this is a bug in the Scala compiler, but that doesn't really matter since Javac also sets the static flag on nested interfaces and enums. In my defense, javac has the following comment:

// Nested interfaces and enums are always STATIC (Spec ???)

The (untested) fix is to override the ReflectiveModifiers property in FakeTypeWrapper in DotNetTypeWrapper.cs:

	internal override Modifiers ReflectiveModifiers
	{
		get
		{
			return Modifiers | Modifiers.Static;
		}
	}

Regards,
Jeroen

> -----Original Message-----
> From: Michael Bayne [mailto:md...@sa...]
> Sent: Tuesday, April 30, 2013 18:39
> To: ikv...@li...
> Subject: [Ikvm-developers] Attributes of synthesized inner interfaces
> 
> Now that I'm making use of IKVM stub classes from Scala (whee!), I'm
> running into a problem due to Scala's compiler being a bit stricter than
> Java's.
> 
> Specifically, when ikvmstub.exe emits synthetic inner-interfaces (in the
> case of the inner Method interface for delegates and the inner
> Annotation interface for attributes), the interfaces are not marked as
> "static", which causes the Scala compiler to think they require an outer
> this pointer to be instantiated. To be sure interfaces must always be
> static, but apparently it would be nice if they were marked as such.
> 
> The javap output from an inner interface compiled by javac reports:
> 
>   InnerClasses:
>        public static #9= #1 of #7; //Method=class NSAction$Method of
> class NSAction
> 
> whereas the javap output from an inner interface generated by
> ikvmstub.exe reports:
> 
>   InnerClasses:
>        public #8= #2 of #7; //Method=class
> cli/MonoTouch/Foundation/NSAction$Method of class
> cli/MonoTouch/Foundation/NSAction
>     IKVM.NET.Assembly: length = 0x2
>      00 0A
> 
> Note "public" versus "public static".
> 
> I'm not familiar with the bytecode format and the generation process,
> but I'm sure this is just a flag that needs to be set somewhere.
> 
> If it's an obvious fix, then yay! If not, I can dig through the
> ikvmstub.exe source and figure out what needs to be done.
> 
> Thanks!
> 
> -- md...@sa... <mailto:md...@sa...>