Android ported to C#

Wow. “One crazy idea that the team had at that dinner was to translate Android’s source code to C#. Android would benefit from C# performance features like structures, P/Invoke, real generics and our more mature runtime. […] We decided it was crazy enough to try. So we started a small skunkworks project with the goal of doing a machine translation of Android from Java to C#. We called this project XobotOS.” Most of Android’s layouts and controls are now in C#. The small benchmark is stunning, but as much as I admire the work, I’m wondering that this like going from bad to worse – from Oracle’s Java to Microsoft’s C#.

53 Comments

It’s a mistake to call a JIT an interpreter. Yes, it’s possible to interpret bytecode, and that’s what Sun’s earliest implementations of Java did. But modern JITs will compile bytecode to native code before ever running it (or, in some cases, after it’s run more than once). The only difference is that compilation is done when needed rather than ahead-of-time.

There are legitimate issues with JIT compilation strategies. The obvious one is startup time: there’s a tradeoff between shorter compilation times and faster code, and so if you have to compile an application every time you run it, then you’re going to do less optimization. But it’s not interpretation.

At least then you bypass the interpretation layer and get a real executable to directly run applications.

Dunno, but (without having tried) it “seems” that only C/C++ are supported via NDK on Android. So maybe GCJ isn’t supported there (and I’m honestly not sure it’s still maintained upstream much, if at all, though I could be wrong).

Are you really surprised? This came from the team that’s responsible for writing Mono, a free version of C#. And anyway, C# is a major language, used by millions of programmers worldwide, and which is an ECMA standard. I have never heard of Vala until just now; based on a quick Google search, it seems to be written by two people in their spare time.

Also, note that a language is not its implementation! It is possible to use any compilation strategy for any language. gcj is an ahead-of-time compiler for Java, and Microsoft produces an ahead-of-time compiler for C# called ngen.

Two people in their spare time – maybe five years ago. It’s now a leading language for developing GTK and Gnome applications, and the language behind the applications made by yorba.org and elementaryos.org.

One of the most fascinating things about it is that it has a syntactic front end for a language almost as elegant and concise as Python that compiles down to machine code, no VM, and has performance and memory footprints near C’s.

Using just the ECMA standard compliant implementation, you are not able to make use of:

– Generics

Section 8.16.1 of the 2006 EMCA 4th edition of the standard seems to contradict you here.

– Nullable types

Again, this is covered in the 4th edition – see section 8.19.

– Dynamic types

These are covered in the current draft spec I believe.

– LINQ

– CLR libraries for parallel programming

LINQ is a class library extension and it not necessary to write software. What is important is Lambda, but even then that is just syntactic sugar.

All of the parallel requirements are in the latest draft spec.

Microsoft stopped updating the standard in 2006.

Strange how there are docs dated 2009 onwards on the Microsoft EMCA site. Specs take time to ratify, so it is not helpful to assume anything till Microsoft make a public statement saying “we no longer support the EMCA and ISO and we withdraw from the CLR/C# standards committee.”

EDIT: The EMCA CLR spec is now on the 5th edition and is dated 2010, so you are even more further from the truth than previously assumed.

Working drafts are future specs. Like I inferred, unless MS retracts support, they will be part of the next spec. Also, a lot of this is already covered by the community promise. Either way, the spreading of FUD due to your own lack of knowledge/agenda is not helpful..

As you say, binary portability is an extremely good reason to have a VM, particularly in the mobile device market where there are a large variety of platforms. Compiling to specific individual targets just is not future-proof. Well designed VM’s just about completely eliminate problems of locked hardware. Also, new JIT compilers can optimize older programs to use new CPU features.

Another benefit of VMs is applications sandboxing as well as eliminating most memory corruption conditions.

Open source and builds are a solution. As much fragmentation as there is for Android phones, it seems like this problem exists anyway. I’m thinking that virtualizing the processor is a better solution – hence using LLVM and compiling the bytecode to machine code.

Vala is tied to the GObject system and is pretty far from a drop in replacement,

It was quite some time ago I looked at Vala but unless I’m mistaken you could write a Vala program without using GObject and also add bindings to any library you wish (either straight up bindings or ‘objectifying’ using a VAPI file).

As I recall the biggest difference is that there’s no full-blown GC but only reference counting and that Vala compiles to C and then to native code.

The only Vala program I’ve used is Shotwell and that is indeed great, certainly way more performant than F-spot was (although I can’t say for sure if that is a question of Vala vs Mono or a matter of the the skill of the actual programmers).

Vala is an object-oriented programming language with a self-hosting compiler that generates C code and uses the GObject system.

That pretty much is what I remember. Vala was also extremely tied to Linux and very hard to build on other platforms. I remember the Windows port being hard to get set up and pretty useless due to the ties to GObjects and GNOME. As this brings in a super large dependency to Android, you must be able to see that using a more platform agnostic compiler makes more sense?

I’m disappointed that they didn’t translate it into Vala which would ditch the VM, but it could be that their work proved the possibilities and moved that forward. Vala is pretty similar to C#.

Only superficially. The language syntax is similar, yes, but that’s where it ends. The runtime environments are completely different, and it’s the similarity of the Java and .NET runtime environments that makes things like this possible.

I agree, you’re right, but I’m very interested in seeing a Linux-based OS for smartphones where any virtualization happens at the machine level, not the runtime library level, hence using stuff like LLVM in a way akin to Taos: http://www.uruk.org/emu/Taos.html

The small benchmark is stunning, but as much as I admire the work, I’m wondering that this like going from bad to worse – from Oracle’s Java to Microsoft’s C#.

First of all, technically speaking, C# is leagues better than Java in many respects, both as a language and an implementation. Some things, like value types, have been strengths of C# since day one. Other things, like generics and lambdas, have been implemented and extended, while Java simply rested on its laurels.

Second, I don’t think Microsoft has shown anywhere near as much bad faith towards the developer community as Oracle. Microsoft has submitted every version of C# to ECMA for standardization. There are multiple free (as in speech) C# compilers and runtime implementations, and unlike Oracle (which is actively suing Google), Microsoft has explicitly promised *not* to sue. And even if they did sue, they would have no case against a compiler which strictly implemented the ECMA spec.

If that’s a Microsoft marketing rep, he’ll have an easy time. From language features to the libraries, C# has been much nicer than Java for years. It’s easy to see how someone could think that Sun/Oracle sat around doing some butt picking and waiting for open source frameworks to fill in the gaping holes in the platform while (poorly) implementing some language features in not quite as nice ways as C# had already done.

I’m not developing on either at the moment, so take that as an un-beholden opinion. No… fact. Take it as a fact.

“….The C# language definition and the CLI are standardized under ISO and Ecma standards that provide reasonable and non-discriminatory licensing protection from patent claims. However, Microsoft uses C# and the CLI in its Base Class Library (BCL) that is the foundation of its proprietary .NET framework, and which provides a variety of non-standardized classes (extended I/O, GUI, Web services, etc.). Some cases where Microsoft patents apply to standards used in the .NET framework are documented by Microsoft and the applicable patents are available on either RAND terms or through Microsoft’s Open Specification Promise that releases patent rights to the public,[35] but there is some concern and debate as to whether there are additional aspects patented by Microsoft that are not covered, which may deter independent implementations of the full framework.

Microsoft has agreed not to sue open source developers for violating patents in non-profit projects for the part of the framework that is covered by the OSP.[36] Microsoft has also agreed not to enforce patents relating to Novell products against Novell’s paying customers[37] with the exception of a list of products that do not explicitly mention C#, .NET or Novell’s implementation of .NET (The Mono Project).[38] However, Novell maintains that Mono does not infringe any Microsoft patents.[39] Microsoft has also made a specific agreement not to enforce patent rights related to the Moonlight browser plugin, which depends on Mono, provided it is obtained through Novell.[40]

In a note posted on the Free Software Foundation’s news website in June 2009, Richard Stallman warned that he believes that “Microsoft is probably planning to force all free C# implementations underground some day using software patents”, and recommended that developers avoid taking what he described as the “gratuitous risk” associated with “depend[ing] on the free C# implementations”.[41] The Free Software Foundation later reiterated its warnings,[42] claiming that the extension of Microsoft Community Promise to the C# and the CLI ECMA specifications[43] would not prevent Microsoft from harming open-source implementations of C#, because many specific Windows libraries included with .NET or Mono were not covered by this promise…””

“Microsoft irrevocably promises not to assert any Microsoft Necessary Claims against you as an open source software developer (“You”) for making, using, importing, or distributing any implementation of a Covered Specification (“Covered Implementation”), subject to the following. This is a personal promise directly from Microsoft to You, and You acknowledge it is a condition of benefiting from it that no Microsoft rights are received from suppliers, distributors, or otherwise by any other person in connection with this promise. To benefit from this promise, You must be a natural or legal person participating in the creation of software code for an open source project. An “open source project” is a software development project the resulting source code of which is freely distributed, modified, or copied pursuant to an open source license. If You engage in the commercial distribution or importation of software derived from an open source project or if You make or use such software outside the scope of creating such software code, You do not benefit from this promise for such distribution or for these other activities.

To clarify, “Microsoft Necessary Claims” are those claims of Microsoft-owned or Microsoft-controlled patents that are necessary to implement the Covered Specification. “Covered Specifications” are listed below. Where a software development project has in all other respects the characteristics of an open source project, distribution among the participants of that project of source code developed by natural persons under an employment contract or by natural or legal persons under a contract to develop is not considered to be commercial distribution, and that software development project does not lose its character as an open source project merely because such distribution takes place among participants. Software is deemed to be commercially distributed within the meaning of this promise when the distributor derives revenues in connection with the distribution, such as from subscriptions, updates, or user-based connection fees or from services that are contractually required for a customer to obtain the current version and/or updates of the software product in question.

This promise is not an assurance either (i) that any of the Microsoft-issued patent claims cover a Covered Implementation or are enforceable or (ii) that a Covered Implementation would not infringe on patents or other intellectual property rights of any third party. No other rights except those expressly stated in this promise shall be deemed granted, waived, or received by implication, exhaustion, estoppel, or otherwise.

Covered Specifications (the promise applies individually to each of these specifications):

“Open Protocol Specifications” (as published at msdn.microsoft.com/openprotocols or its successor site) for the protocols implemented in the current and future versions of Windows Vista including the .NET Framework, Windows Server 2008, SQL Server 2008, Office 2007, Exchange 2007, and Office SharePoint Server 2007, that are used by any other Microsoft product to connect with these products.”

Android derives revenues in terms of adds but only indirectly. Will Android thus qualify?

I’m not a lawyer, but I think it’s very doubtful that you would infringe a Microsoft patent simply by *using* a programming language. That would be the equivalent of saying that every file you save in Emacs, or every program you compile with GCC, has to use the GPL.

Now, if someone (like Google) produced their own for-profit implementation of C#, including the non-standardized parts of the BCL, then I don’t know. But that’s a risk that anyone takes when trying to duplicate something that isn’t standardized. It’s unfortunate, but it has nothing to do with C# as a language.

I agree. Plus Google could argue that M$ (yes, I did that on purpose!) is already extracting royalties from Android (by proxy, from the cellphone manufacturers), so Google don’t have to pay them – again – for just using C#.

I always wondered why google picked up java for android especially since they use python pretty much everywhere, I understand that java is probably the most used language right now so it would be easier to attract more developers but as a developer myself I find android programming a huge mess, I don’t know how it is on ios but I think that wp7 is pretty much the same as .net/silverlight wpf and that’s just beautiful compared to android

Yes, it seems Java is #1 by far, but yeah, I agree, it’s still a weird choice (IMO). Though I guess things like ARM’s Jazelle / JIT help a lot. So you’ve got lots of programmers for it by default, which is good for lots of apps. But why not Python? Dunno (though with SL4A you can now use Python, among others), perhaps it’s too slow. Unladen Swallow was Google’s attempt at fixing that (right?), but they eventually gave up on that. Or maybe they intend Go as a future solution? Or maybe C++11? Who knows, it’s a complicated world.

Google talked about doing Android in C# but decided against it because at the time they were making the choice Java was a sun product and it likely seemed less evil than Microsoft at the time.

Either way, why not just apply for a license from Microsoft just to know they are covered? I can just about promise that they are considering it and talking with Microsoft about the terms.

The problem with that decision is Visual Studio and C# are already a really good development platform for Windows Phone and having Android on C# would translate to a huge influx of Windows Phone applications and developers.

If Microsoft were smart they would be knocking on Google’s door with “we promise not to sue you for using C#” papers because they would instantly become relevant in the mobile space again and many others in the industry might follow the Java to C# transition in the process.

Google talked about doing Android in C# but decided against it because at the time they were making the choice Java was a sun product and it likely seemed less evil than Microsoft at the time.

Either way, why not just apply for a license from Microsoft just to know they are covered? I can just about promise that they are considering it and talking with Microsoft about the terms.

The problem with that decision is Visual Studio and C# are already a really good development platform for Windows Phone and having Android on C# would translate to a huge influx of Windows Phone applications and developers.

If Microsoft were smart they would be knocking on Google’s door with “we promise not to sue you for using C#” papers because they would instantly become relevant in the mobile space again and many others in the industry might follow the Java to C# transition in the process.

The problem is software patents are incompatible with open source. Google wants to produce and open source operating system. Microsoft and Apple hates open source so they use software patents to drive open source out of the marketplace.

Depends on definition. On a technical level? No. I think they have enough evidence that their VM creams Dalvik. From a litigation stand point? Well, no, not from Microsoft. The EMCA standard covers the base libraries, and the greater API is obviously based on a translation of the Java based Android API, not anything from Microsoft. What I would be weary of is Oracle. As it is te API they seemingly have issue with, this might also apply to the machine translated Android API in C#. THERE is your danger. That and the fact that Xamarin are out to make money and will charge an arm and a leg for any products derived from this technology, just as they did with iOS.

It looks like CodeGear and the Delphi trademark are now owned by Embarcadero technologies. They might make a good acquisition for Google and to be honest Google probably should have bought up CodeGear for the ~23 million Embarcadero paid Borland for it in 2008.

Also, to add to this, the primary developer responsible for Delphi eventually went on to work at Microsoft to make J++ and C#. Partly because of this extending Delphi to do what Google needs it to do would legally be cleaner than starting from scratch.

I can’t believe the load of bull love for C#, it’s not that great, I would take Free Pascal over C# any day.

Pascal is a compiled language with no garbage collection. C# is a garbage collected language that targets a VM. <sarcasm> Yes, I can see why they are exactly the same. </sarcasm> You may as well have said “why don’t they use Python” or some other random language. Object Pascal is something I did as a day job for over 10 years, I know enough to tell you that you are delusional.

You also don’t even know basic facts about C# and the CLR, as proven by your next statement:

P/Invoke is a freaking pain in the ass, I don’t have to do any of that crap with Free Pascal and or Delphi

You prove you are clueless. Yes you do. Frequently. How do you import a function in a library in Borland’s Object Pascal dialect?

procedure Foo(X: Integer); external ‘BAR’;

How do you do this in C#?

[DllImport(“bar.dll”)] void Foo( int X);

Or, if you are going to be pedantic and insist on Pascal, in Delphi Prism :

[DllImport(“bar.dll”)] procedure Foo(X: integer); external;

Yeah, so very different and so very hard. <sarcasm> Let’s hate on P/Invoke because the syntax is just ridiculously complicated, yeah, impossible… </sarcasm>

and I have Generics etc.

No, you have “kinds of generics”. The FreePascal version is more like templates (and depending on compiler build can be quite broken in my experience) and the Delphi version depends on which flavour you mean. Delphi Prism uses .Net, Delphi for Windows uses Borland/Codegear “version” and Delphi for Mac OS X and iOS uses FreePascal, which is not an exact analogue.

Pascal is a compiled language with no garbage collection. C# is a garbage collected language that targets a VM. Yes, I can see why they are exactly the same.

FPC now has optional JVM target support. Also, don’t forget that Pascal’s cousin, Oberon, does have garbage collection. So it’s not that far of a stretch.

and I have Generics etc.

No, you have “kinds of generics”. The FreePascal version is more like templates (and depending on compiler build can be quite broken in my experience) and the Delphi version depends on which flavour you mean.

I could be wrong, but I think FPC now supports both kinds of generics (their own and the Delphi variant).

Almost a recipe on how to make a benchmark that look good for you, you first select an area where your language/implementation is better, no matter how useful or useless is that area to “real” application. Then you write a benchmark, and how surprise, it shows that your language/implementation is faster. But it does not mean that the applications written in C# will be faster, it might just be that Google has considered that those algorithm were not worth being optimised.