{"id":6934,"date":"2014-05-11T17:47:35","date_gmt":"2014-05-11T17:47:35","guid":{"rendered":"https:\/\/unknownerror.org\/index.php\/2014\/05\/11\/getting-java-net-malformedurlexception-in-monodeveloper-collection-of-common-programming-errors\/"},"modified":"2014-05-11T17:47:35","modified_gmt":"2014-05-11T17:47:35","slug":"getting-java-net-malformedurlexception-in-monodeveloper-collection-of-common-programming-errors","status":"publish","type":"post","link":"https:\/\/unknownerror.org\/index.php\/2014\/05\/11\/getting-java-net-malformedurlexception-in-monodeveloper-collection-of-common-programming-errors\/","title":{"rendered":"Getting java.net.MalformedURLException in MonoDeveloper-Collection of common programming errors"},"content":{"rendered":"<p>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 <strong>executables<\/strong> bigger than 60MB.<\/p>\n<p>That&#8217;s huge, a basic hello world application created with Xamarin.iOS is under 3 MB and that&#8217;s the total <strong>application<\/strong> size. The executable itself is under 2.2MB and includes the Mono runtime, the <em>linked<\/em> base class libraries (BCL) and the <em>unlinked<\/em> user code.<\/p>\n<p>Now this 2.2MB size is achieved because the BCL is <strong>linked<\/strong> (by default <strong>Link SDK<\/strong> is used for device builds). That means everything that is <strong>not<\/strong> used, in the BCL, is removed. If the BCL was <strong>not<\/strong> linked (it can be disabled if you&#8217;re curious) then the executable size would be <strong>46 MB<\/strong> &#8211; more than 20x bigger! (and that&#8217;s part of the reasons why you should <strong>never<\/strong> disable the linker on device builds).<\/p>\n<p>LibGDX is a Java library. It can work with Xamarin.iOS by being converted to .NET using IKVM. That converts the GDX library <strong>and<\/strong> the Java class libraries. All of this is <strong>user code<\/strong> (i.e. stuff you added) and not <strong>SDK<\/strong> code (i.e. code shipped by Xamarin). IOW the linker does not, by default, remove anything from GDX (or IKVM libraries).<\/p>\n<p>So, <strong>by default<\/strong>, everything in GDX <strong>and<\/strong> Java (class lib) is being AOT&#8217;ed into the native executable &#8211; leading it over Apple&#8217;s limit (which was the previous question).<\/p>\n<p>The previous answer was to use <strong>Link all assemblies<\/strong>, 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).<\/p>\n<p>However it goes back to the main linker limitation. It use static analysis to detect unused code &#8211; and reflection (from .NET or Java) is dynamic. So the linker needs help to preserve (using <code>[Preserve]<\/code> attribute or an XML file) code used thru reflection.<\/p>\n<p>I have <strong>not<\/strong> seen the Java code handling protocols &#8211; but I&#8217;m pretty sure it use reflection to load a type based on the scheme (e.g. <code>file<\/code>) and that type(s) needs to be preserved to work correctly at runtime. Once preserved I&#8217;m sure the application will work properly (and without being improperly large).<\/p>\n","protected":false},"excerpt":{"rendered":"<p>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&#8217;s huge, a basic hello world application created with Xamarin.iOS is under 3 MB and that&#8217;s the total application size. The executable itself is under 2.2MB [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-6934","post","type-post","status-publish","format-standard","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/6934","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/comments?post=6934"}],"version-history":[{"count":0,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/posts\/6934\/revisions"}],"wp:attachment":[{"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/media?parent=6934"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/categories?post=6934"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/unknownerror.org\/index.php\/wp-json\/wp\/v2\/tags?post=6934"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}