On Aug 30, 2012, at 2:44 AM, Igor Russkih <iruss...@gmail.com> wrote: > C:\Program Files\MSBuild\Novell\Novell.MonoDroid.Common.targets(690,3): > error MSB4018: The "GenerateJavaStubs" task failed unexpectedly. > C:\Program Files\MSBuild\Novell\Novell.MonoDroid.Common.targets(690,3): > error MSB4018: System.ApplicationException: Failed to create JavaTypeInfo for > class: ab ---> System.InvalidOperationException: The Name property must be a > fully qualified 'package.TypeName' value, and no package was found for 'ab'.
Java.Lang.Object subclasses only need to contain a package if their name will be used in AndroidManifest.xml. (Android!!! /me shakes hand in air.) > Is it possible to do some 'normalization' of symbols when generating .java - > to support this? I'm not sure. Obfuscators can potentially rename ~everything (class names, method names, field names). If your obfuscator were to process Mono.Android.dll, it could then rename virtual methods in all subclasses; I'm sure this is "do-able", and would result in semantically valid IL (as long as all assemblies were corrected). The problem is the Mono.Android.dll implementation which looks up many methods via Reflection, by-name, and if these methods are renamed then all bets are off and things will break horribly. For example, while we could normalize type names so that they're valid Java identifiers, will method names get screwed up? I suspect not -- the method names are retrieved from the [Register] custom attribute, which (presumably) the obfuscator will leave alone, so normalizing Java type names is something that could be done. Would that be effective? I don't know. - Jon _______________________________________________ Monodroid mailing list Monodroid@lists.ximian.com UNSUBSCRIBE INFORMATION: http://lists.ximian.com/mailman/listinfo/monodroid
