Getting java.net.MalformedURLException in MonoDeveloper-Collection of common programming errors

Based on a past question (from the same user) I think this is the output of a chain reaction. Apple recently began to refuse application executables bigger than 60MB.

That’s huge, a basic hello world application created with Xamarin.iOS is under 3 MB and that’s the total application size. The executable itself is under 2.2MB and includes the Mono runtime, the linked base class libraries (BCL) and the unlinked user code.

Now this 2.2MB size is achieved because the BCL is linked (by default Link SDK is used for device builds). That means everything that is not used, in the BCL, is removed. If the BCL was not linked (it can be disabled if you’re curious) then the executable size would be 46 MB – more than 20x bigger! (and that’s part of the reasons why you should never disable the linker on device builds).

LibGDX is a Java library. It can work with Xamarin.iOS by being converted to .NET using IKVM. That converts the GDX library and the Java class libraries. All of this is user code (i.e. stuff you added) and not SDK code (i.e. code shipped by Xamarin). IOW the linker does not, by default, remove anything from GDX (or IKVM libraries).

So, by default, everything in GDX and Java (class lib) is being AOT’ed into the native executable – leading it over Apple’s limit (which was the previous question).

The previous answer was to use Link all assemblies, IOW run the linker on all the application managed code. That removes a lot of unused code and results in smaller applications and executable size (see the hello world example above).

However it goes back to the main linker limitation. It use static analysis to detect unused code – and reflection (from .NET or Java) is dynamic. So the linker needs help to preserve (using [Preserve] attribute or an XML file) code used thru reflection.

I have not seen the Java code handling protocols – but I’m pretty sure it use reflection to load a type based on the scheme (e.g. file) and that type(s) needs to be preserved to work correctly at runtime. Once preserved I’m sure the application will work properly (and without being improperly large).