|Summary:||ACWs: Create unique package names instead of lowercasing the namespace|
|Product:||Android||Reporter:||Jonathan Pryor <jonp>|
|Component:||MSBuild||Assignee:||Jonathan Pryor <jonp>|
|Severity:||enhancement||CC:||chris, mono-bugs+monodroid, paul.batum, perfinica_appdev_ch, peter.collins|
|Tags:||Is this bug a regression?:||---|
|Last known good build:|
Description Jonathan Pryor 2013-12-16 14:43:27 UTC
First (public?) bug on the X.0 breaking change TODO list: The ACW generation code shouldn't lowercase the namespace name to generate the package name. Instead, it should generate unique names based on namespace+assembly name (e.g. use MD5(Type.AssemblyQualifiedName) as the package name). This would be a breaking change, because we've previously documented that the package name is the lowercased namespace name, and used this as a workaround for all manner of historical bugs. Rationale: 1. It's uncommon, but not impossible, for two types to have the same namespace+type name but be present in two different assemblies: https://bugzilla.xamarin.com/show_bug.cgi?id=15205#c1 https://bugzilla.xamarin.com/show_bug.cgi?id=16805 2. At least once in the past a customer ran into issues because the Java package name was "too long." (I'm not sure what "too long" was, but the package name was dozens+ of characters in length, and iirc they were either running afoul of Windows' MAX_PATH limit, or Android didn't like their crazy long package name either.) Encoding the namespace+assembly into a fixed-size package name would avoid this issue. Note that this could be disabled on a type-by-type basis by using e.g. ActivityAttribute.Name to set an explicit ACW name. Potential Problem: Performance. Internally we need to navigate from Managed names to JNI names, and vice versa. (This could probably use some profiling love, too.) * Managed > JNI is (currently) done by lowercasing the namespace + JNIEnv.FindClass(), and only if that fails do we lookup the custom attributes to find any alternate names. (Note: this may in fact be stupid. Profile!) The above "always encode" scheme would require an entirely different mechanism for type mapping. * JNI > Managed is (currently) done by PascalCasing the package name. It's also quite flaky, and offhand I don't know if this is actually used. occasionally we need to go from a JNI type name to a C# type name, and that currently works by attempting to PascalCase the JNI name into a C# name, and only if that fails do we fallback to
Comment 1 Jonathan Pryor 2014-02-06 15:20:25 UTC
*** Bug 17642 has been marked as a duplicate of this bug. ***
Comment 2 Jonathan Pryor 2014-08-13 10:33:35 UTC
*** Bug 21147 has been marked as a duplicate of this bug. ***
Comment 3 Paul Batum 2014-08-13 20:32:48 UTC
Is there an ETA for taking this change? We maintain a library that is impacted by this issue and so it would be great if we could get an idea of when a fix might be available. Thanks, Paul
Comment 4 Jonathan Pryor 2014-08-13 23:13:43 UTC
> Is there an ETA for taking this change This is a gigantic semantic change, and could wreak untold and unknowable havoc: ALL instances where developers assume the ACW name will be invalidated. (Mind you, it's "easily" fixable by using [Register] or [Activity(Name="my/alternate/TypeName")], but it will still break existing code.) As such, I can't in good conscience do this before an ABI break. Good news: we're planning on a 5.0 release some time this fall to coincide with Android API-L going stable (which I'm assuming will likewise be 5.0), and this will allow us to perform some ABI breaks. Bad news: I'm not confident in being able to get this change in place in that timeframe. So the answer is either "within the next few months" or "over a year from now."
Comment 5 Paul Batum 2014-08-17 23:54:07 UTC
OK, thanks for the info Jonathan, we appreciate it!
Comment 6 Jonathan Pryor 2014-10-15 21:52:52 UTC
Fixed in monodroid/eb04c91c.
Comment 7 Paul Batum 2014-10-19 21:59:13 UTC
I see that 21147 has been marked as a duplicate of this bug. In the case of 21147, the issue of not being able to load two types with the same full name from two different assemblies exists for both iOS and Android. This bug covers the Xamarin.Android side, is the same issue already fixed for Xamarin.iOS?
Comment 8 Jonathan Pryor 2015-03-12 21:47:27 UTC
@Paul: > is the same issue already fixed for Xamarin.iOS? Bug #21147, as I understood it, was only for Android, not for iOS. The only places "iOS" shows up in Bug #21147 is in the IDE version information dumps and in your question at: https://bugzilla.xamarin.com/show_bug.cgi?id=21147#c17 If there is an iOS equivalent to this bug, it should be filed as a separate bug.