Related
Edit: My bad, I meant objective-c, not c#. Some reason I got it into my head it was c# the iphone used. So the answers for c# were great, thanks, but theyre a bit irrelevant, sorry about that.
I've had a look but can't find anything that answers this, though a few have shortened the question by answering parts of it. Between a small group, we were planning on doing some work on iPhone and Android, the 2 seperate for the most part but helping each other out, and with some guys doing graphics work split between them.
But we were thinking about the possibilities of moving things between the two, not necessarily apps, maybe just useful classes or something. Looking at objective-c and Java, they seem to have about the same features that the biggest obstacle would be system interface stuff, so we were wondering whether, if we created an abstraction over these on each system so they could be given the same input (which unless I'm wrong wouldn't put too much strain on the system?), would there be any problems in writing something to convert between objective-c and Java, worse than the locations of methods in the sdks? Or are there key features or something in one language that the other doesn't have which we've missed that would mean the only way to do it would be rewriting from scratch.
I wouldn't waste time trying to find commonality between iOS and Android.
Cross-platform is almost always a waste of time and resources unless the cross-platform capability is central to the apps functioning. That is especially true for platforms such as iPhone and Android which have custom OS and work very tightly with the hardware.
Cross-platform development environments add rather than reduce complexity long term. Yeah, it sounds neat but usually you get 90% what you want easily and then you hit a roadblock that destroys all the savings you made and then starts putting you in the hole. There are simply to many compromises and square pegs jammed into round holes.
Unless your app could in theory work from a generic web page, cross-platform is not for you.
In the specific case of Objective-C and Java, although Java is descended from Objective-C they have no modern interoperability. You can't use code from one on the other.
You should spend the time to learn each platform's specific API. There are no shortcuts.
Tools like XMLVM, Codename One and iSpectrum tell us that you can actually cross-compile Java code (from an Android app or creating one from scratch) to Objective-C code that is running on an iPhone without having to install any virtual machine on the Apple side of things.
I suggest watching Developing iPhone Applications using Java
Unfortunately Apple's license
agreement for the iPhone SDK prohibits
the porting of the Java virtual
machine to the iPhone. In this
presentation we introduce an Open
Source Java-to-Objective-C
cross-compiler as well as a Java-based
implementation of the Cocoa library.
With the help of these tools, iPhone
applications can be written in pure
Java. Using the Java version of Cocoa,
it is possible to run a Java-based
iPhone application as a Java
desktop/applet application that can be
cross-compiled to run natively on the
iPhone. The talk will discuss the
challenges of the Java-to-Objective-C
cross-compiler as well as the
Java-based version of Cocoa. Details
are available at http://www.xmlvm.org/
and for more insight a more recent talk about Cross-Compiling Android applications to the iPhone from Frebruary 2010 is available here, which is documented at http://www.xmlvm.org/android/ :
Android is an Open Source platform for mobile devices. Initiated by Google, Android has received much attention. Android applications are developed using Java, although a special compiler converts class files to a proprietary, register-based virtual machine that is used on Android devices to execute applications. Android defines its own API for writing mobile applications. With the help of XMLVM it is possible to cross-compile Java-based Android applications to native iPhone applications.
The Android application is written in
Java and makes use of an Android
specific API. XMLVM offers a
compatibility library, written in
Java, that offers the same API as
Android, but only makes use of the
Java-based API for Cocoa Touch. During
the cross-compilation process, both
the application and the Android
compatibility library are
cross-compiled from Java to
Objective-C and linked with the Cocoa
Touch compatibility library to yield a
native iPhone application.
From the 2008 talk about building Java applications for the iPhone http://www.xmlvm.org/iphone/ :
Apple's iPhone has generated huge
interest amongst users and developers
alike. Like MacOS X, the iPhone
development environment is based on
Objective-C as the development
language and Cocoa for the GUI
library. The iPhone SDK license
agreement does not permit the
development of a virtual machine.
Using XMLVM, we circumvent this
problem by cross-compiling Java to the
iPhone. Just like a Java application
can be cross-compiled to AJAX, XMLVM
can be used to cross-compile a Java
application to Objective-C. The
cross-compilation is also accomplished
by mimicking a stack-based machine in
Objective-C.
If you focus on abstracting away things like system interactions, and stick to the common subset of the languages, you can probably build classes that would require little or no modification to move from one language to the other.
C# does have a better implementation of generics than Java, in that C#'s generics retain strong typing at run-time.
C# also has LINQ, which as far as I know has no equivalent (yet) in Java. LINQ provides a SQL-like query capability, built into the language and fully supported by the .NET frameowrk, that lets you query object collections, and does so in a very functional-language style. LINQ can be extended by query providers to work with other data formats, such as XML and SQL, once the query provider provides an object model that translates to the other format. LINQ also makes parallelization very easy for multi-core work. It's a huge extension to language capability.
This topic is often filled with the dogma of technology jihadis, so I shall try and steer clear of that in my answer.
In my experience, I would largely agree with people saying that trying to share code between the two platforms would be difficult. However, there are some important exceptions:
I would consider cross-platform development where your business logic:
is non-trivial;
should be standardized across platforms; and
has well defined interactions with the outside world (e.g. network stack or UI).
(bonus) is written already.
Apple is the rate determining step here, given the now infamous 3.3.1 restrictions on source code languages. You can write code in Javascript according to the bundled Webkit, C, C++ and Objective C.
If you don't want to install extra languages on a 'droid, you can use the Java that compiles down to dalvik code, the Javascript as per the slightly different build of webkit or something from the NDK. Then you'll be looking at C/C++. You could cross-compile Objective-C, but I haven't had any experience of that.
The clean separation of business logic from UI and networking is important, as you'll be looking to write adapters for the networking layer, something else for the UI.
I would not attempt to write cross platform UI code in C/C++, and would either write something that used HTML/CSS/JS, or more likely write something completely custom to take advantage of the different UI metaphors on each platforms - e.g. there is no analogue to the notification bar on the iPhone. Animation on the iPhone is orders of magnitude simpler to implement than on Android.
If you don't need the UI to be massively integrated with the OS, then a webview and some HTML5 may be sufficient. Titanium is a good option here, and my colleagues in the know tell me it is better (i.e. compiles, not interpreted) than PhoneGap. Again I don't know.
Going the other way in complexity, Open GLES is available on both platforms.
It should also be noted that SVG is not available on the current crop of Android OSes.
If you actually want to do cross phone development, as long as it is not something really computationally expensive, I would probably go with PhoneGap.
PhoneGap is an open source development framework for building cross-platform mobile apps. Build apps in HTML and JavaScript and still take advantage of core features in iPhone/iTouch, iPad, Google Android, Palm, Symbian and Blackberry SDKs.
As far as I can tell, it's pretty much the only cross platform toolkit that is allowed in the iPhone app store.
If you're dead set on native development, I think you'll find that unless you're making a game and targeting c, it will be a lot of work to port. The frameworks are very different and the way of building UI is very different. That said, to answer you're direct question of objective-c vs. java, it's not that bad. It is different enough, though, that an abstraction tool would not be that easy - not like Java vs C#. Objective-c does not have garbage collection (on the iPhone anyway), for example, and the syntax is very different. Objective-c is more loosely typed in the way that it does method calls (messages in objective-c). That said, they aren't wildly different in terms of programming paradigms. They are both object oriented imperative languages. They both have classes and methods, public and private. If you wanted to port the code by hand, it wouldn't be the end of the world, I just think you might wind up spending a lot more time trying to build an abstraction layer.
If you're thinking about doing Android development my best advice is to go for java. There is no benefit at all of writing a complete abstraction (assuming you can) layer to convert from C# to Java. As for the IPhone development dont doubt about using Objective-C for the same purpose.
You can't develop for the iPhone in the same language as for Android. For the iPhone, you can only program in Objective C, it's developed by Apple. You can't use it for android, and the only way to do iPhone development is with that language (it's in the user agreement).
As for C# vs. Java, the whole principle is different. Java is one language for every platform, .Net is one platform for every language. They are not compatible. You can use Java on Android, but I'm not sure if you can use C# (.Net) as well.
Anyway, you'll have to build two different apps for these two mobile operating systems.
I absolutely love good defender games (e.g. Gemcraft, Protector: reclaiming the throne) as they can be intellectually quite challenging; it's like playing chess but a little less thinking and a bit more action. Sadly, there are not that many good ones out there and I thought I would create one myself and share it with the rest of the world by making it available on-line.
I have never worked with ActionScript but when it comes to on-line games, this is the main choice. I have tried to find a decent 2D game in the form of a Java applet but to no avail. Why is this so? I could write the game, most comfortably, in Delphi for Win32 but then people would need to download the executable, which could deter some form downloading it, and also it would only work on Windows. I am also familiar with Java, having worked with Java for the last four years or so; although, I don't have much experience with games programming.
Should I not be deterred by the fact that all on-line games are written for in Flash and create my defender game as a Java applet, or should I consider learning ActionScript and games development for the ActionScript Virtual Machine (AS3 looks very much like Java... but still, it's an entirely new technology to me and I might never use it professionally.)
Could you, please, just answer the the question in the title? Why Flash, not Java applets? Is it only 'politics'?
Flash is more popular since its penetration rate is huge.
Flash is also more powerful when it comes to create and integrate graphics assets (since Flash CS* is also a vector animation editor).
It's also very easy to embed sounds and fonts assets, to play with bitmap effects, without using any aditional library.
And last but not least, there's a lot of sites who offers ActionScript APIs in order to earn money with your games by adding various ads in it (such as MochiMedia, Kongregate...)
Flash provides a fully-built graphics and sound engine that will handle separate objects ("sprites") on paths and animation.
In Java those features would need to be provided by third-party library. Java does provides the necessary building stones to build such an engine, however.
JavaFX might change this, however.
I can provide a little insight on the Java side: Early in the history of Java, Sun tried to push Java applets as the new way to display dynamic content in a browser. This attempt was doomed to failure by the combination of the following factors:
Java had (and still has) a lengthy load time for the (JRE) runtime;
Java originally had only AWT as a GUI toolkit, and AWT is limited and really ugly;
Java used to be a lot slower before the advent of faster CPUs and JIT compiling;
Java was (many think intentionally) supported very half-heartedly by Microsoft in IE, so it wasn't well integrated and ran poorly.
All this gave Java (deservedly) a horrible reputation, from which desktop and browser Java have still not recovered. To most people, Java stands for ugly, slow and often not working applications. It still suffers from this stigma today.
While both Java and Flash are Turing complete programmng environments, Java is more universal, with a bigger set of libraries for all kinds of different purposes. Sun strove to have the Java environment be universal among platforms, so browser-side Java includes a lot of libraries that are usually not needed. Again, more load time.
Simple answer: the flash player is installed in almost all of PCs, but JRE isn't.
Flash has a much wider install base, that can be the only reason. I personally don't install Java on my machines....flash, of course.
Why write something for a far smaller audience? I'm not saying it's wrong to, but that's usually the reason when you're making games for a profit.
Think of this equivalent with consoles, with the second generation playstation there were hardware add-ons available...but they were useless unless the games used them. You had 3 options as a game developer, package it with your product - driving the price up, assume they have it - smaller audience, or assume they don't - maximum audience, maximum profit. The result is the hardware never really sold much because as a game developer you had to assume they didn't have it.
For me, that equates that to Java vs Flash, if I have to install it, the price for me accessing it goes up...assuming they have the most common thing and you're safe, minimum cost of entry, maximum audience.
However, if you have a great game, I could be convinced to install :)
Flash typically performs better at the kind of drawing, animation and video features that games require, since that's what it was originally designed for. In addition, the strict-OO nature of the Java language does not lend itself well to the kind of ad-hoc rapid development environment that is common for games.
More importantly from an author's point of views, Flash is by far the more commonly-deployed browser plugin. Java just doesn't have the penetration on the desktop. Applets were historically despised for their instability and poor performance (particularly slow startup); whilst that has improved somewhat, Sun are continuing to undermine what user acceptance they have left with their obnoxious bundling updater. It is a brave company that develops anything much for desktop Java these days.
should I consider learning ActionScript and games development for the ActionScript Virtual Machine
It's definitely worth learning JavaScript/ActionScript. (They're almost the same language, sharing a standardised common core.) Then you can apply your Flash scripting knowledge to browser scripting. You can even consider implementing games in JavaScript/HTML itself!
AS3 looks very much like Java...
In as much as it's a C-like-language, yes. However the concepts and practice are very different; you'll have difficulty if you try to write JS/AS like Java.
A lot of flash developers are designers who have crossed over into making games. They used flash as a design tool before a programming tool.
Plus it seems to be something of a precedent now for online games to be written in flash so I guess people do not want to deviate from "the norm"
Future Flash CS5 could creates iPhone applications directly, so you'll be creating games for 2 platform at the same time.
For the program idea I have, it requires that the software be written in one binary that is executeable by all major desktop platforms, meaning it needs an interpreted language or a language within a JVM. Either is fine with me, but the programming language has to balance power & simplicity (e.g. Python)
I know of wxPython but I have read that it's support on Mac OS X is fairly limited
Java sounds good & it looks good but it seems almost too difficult to program in
Any help?
I used Python with wxPython for quite a while and found it very easy to use. I now use Java with both Swing and SWT.
I prefer Java but that's just a personal preference so you shouldn't let that sway you.
I didn't find the transition from Python to Java that difficult. In terms of GUI, they both have the layout manager paradigm - the managers are different but not so different you'll have trouble switching.
Java has an absolute huge class library to the point where you probably don't need to write your own version of anything, just string together the components. I never really got that deep into Python but it may well be similar. One thing I did notice is that all the really good stuff I used in Python (e.g., s[-4:-1]) could still be done quite easily in Java. Both languages were a step up from C where I had to manage strings with my own libraries.
If you think wxPython is limited on MacOS, you should try Java. I run my Java code on Windows, Linux and other UNIXes without compatibility problems. Sadly, not Mac, so I can't really advise you there.
My advice, pick a smallish project - do it in both Python and Java - see how it runs on all the platforms you're interested in.
Python with PyQt or the eventually-to-be-equivalent-but-gratis PySide seems the way to go -- after all, few languages are easier to program in than Java (which you consider "almost too difficult to program in"), Python is one of those few, Qt arguably the best cross-platform GUI toolkit in any language, and PyQt (now, but GPL or for-$$$) or PySide (eventually, gratis even if you want to close-source your own code) are powerful interfaces between Python and Qt.
You can use any of languages targeting JVM, e.g. Jython (Python impl) and JRuby (Ruby impl).
You can try using Qt bindings for Python, Qt seems to support many of Mac OSX specifics.
Consider Tcl/Tk. I'm not sure how you define "one binary that is executeable [sic] by all major desktop platforms" but Tcl probably meets this as well as java, and likely better than any other scripting language.
Using the tcl packaging technology of starkits you can either a) create a single file that can be run on any platform that has an appropriate runtime engine (and they are available for all major and many minor platforms), or you can package that platform-specific runtime engine and and cross-platform starkit into a single file executable for each platform.
The starkit technology is something other languages should aspire to. What you get is a complete, fully functional virtual file system within a single file. This lets you easily package up sound files, dll/.so files (which must be copied to disk for obvious (?) reasons), images, data, etc along with your executable code.
Tk, the graphical library, is very mature and has really good support on all platforms. Some people think it looks dated but those impressions are usually based on information that is at least 5 years old. Modern Tk looks quite good. For some examples see the tkdocs website. I's not clear whether you're more concerned with eye candy or functionality, but if it's functionality you're interested in then Tk is something to seriously consider.
Most agree that Tcl is an aquired taste but those that use it professionally usually swear by it. I've been doing wxPython programming the last several months and would switch back to tcl/tk in a heartbeat if given the opportunity.
You could use Groovy to work around the Java complexities.
Still you'll need good foundations of Swing.
While the learning curve may be steep, the trade of of not having to completely re-write the whole application again for the next platform will be a good reward.
Bear in mind, that even though it is cross platform, you should consider different platforms still have different idioms ( e.g. Copy/Past in Windows is ctrl+v, ctrl+v while in Mac it is cmd+c, cmd+v )
I work on a program that has to run on Windows, Linux and OS X (and OS X is my development platform), and wxPython is what we use.
If I had a chance to start again, I'd probably go with PyQT (based on advice from friends), but wxPython will get the job done.
I think wxPython is pretty good, though I am not sure what you mean by "support on Mac OS X is fairly limited" but I have been porting a wxPython app (www.mockupscreens.com) to Mac and it wasn't that difficult with few tweaks e.g. some UI elements may not come up as you expected, as wxPython uses native UI elements, which can be an advanatage or disadvantage based on your requirements.
Other good option is PyQT which will give you consistent look on all platforms.
Java seems better for what you want.
Well what about the web application in Javascript?
How about SWT
Cross Platform
Native Look and feel
Huge community
Constantly maintained/upgraded ( IBM backed )
Atleast one mega successful cross platform project
I would suggest going the wxPython route, I know that wxWidgets (which is what wxPython is using) can be made to have great looking Mac apps (look at PgAdmin3 from postgresql). While PgAdmin3 is not done in python, it was done with wxWidgets and looks fine on a mac.
I use three cross-platform tools regularly: Realbasic from Realsoftware which is what Visual Basic v6 would have been if allowed to grow; Revolution from Runrev which is what Hypercard would have been if allowed to survive (and its neat using a scripting language whose syntax is basically English); and finally, Delphi Prism with Mono.
All are quite mature and yet expanding at a great rate. For instance, Revolution is just introducing a web-application feature to its language that is really easy to use.
A few years ago client Java was unsuitable for web development because a remarkable part of web users did not have Java installed. ( I don't remember exact numbers, more than 10%).
Now I see the Google Analytics stats for a big site and it tells that >98% of users have Java installed.
Is these stats very biased by Javascript usage? As I understand Google Analytics measure only users that has Javascript.
Is the picture similar on other big sites?
Does client Java have really "stopper" drawbacks compared to Flash?
EDIT: I mean java applets mainly, java WebStart seems to be not suitable for average user.
I mention Javascript only to describe the way Google Analytics works.
When I wrote my diploma project, I had to choose between Flash and Java Applets. Here are some pros and cons:
Java Applets:
[plus] you program in Java, which is mature and stable
[plus] you can use the Java GUI frameworks that pack a lot of punch
[minus] the first time the user hits the page with the applet, the JVM must be initialized and this can take up to a few minutes even on a fast computer
[minus] Applets are not meant to be used as animation media; sure, you can do stuff, but it is like programming in C - you do everything from scratch
example: i needed to show a data packet as it moved between two routers. The packet must be a control of some sort, like a button or smth. This animation can be defined in 1 line of code in Flash, where all objects derive from some base object that can be animated. I could not find a suitable solution in Java.
Flash:
[plus] really really focused on animations;
[plus] ActionScript is actually an OO language
[minus] ActionScript is sloppy, bughish and has only a few supporters. If you are stuck, be prepared to search obscure Japanese forums for solutions
[minus] ActionSCript may be OO, but it lacks a lot of features, like Enums, fully fledged interfaces, threads (!!!!) etc.
[minus] Flash was designed to be used by non-tech people - they just use the authoring tool; I wrote code for everything and it worked, but it was a pain.
My conclusion:
I eagerly await a programming paradigm for animations and rich client interfaces.
ps: Silverlight seems to be a disappointment so far, maybe Microsoft will inject some $ into it.
Mmm, Java seems to be better supported than I though, I searched some stats and found between 92 and 96% of browsers support Java (ie. it is enabled enough to detect it! although I guess lot of Java detection algorithms use JavaScript to detect & report - as you point out - but JS support is very good too anyway, even more in our Web 2.0 era).
Adobe boasts better support, but overall the difference is rather marginal. Anyway, somebody really wanting to see/use the application will activate/upgrade/download the needed engine.
Now, we have to see what JRE is supported! Alas, I didn't found any stat for that.
There, Adobe have an edge: not everybody have Flash 9 or 10, but upgrading is quite fast. While downloading and installing a new JRE is quite a bigger task... Of course, you can target the historical lowest common denominator Java 1.1, or more realistically Java 2 (1.4), but it is still frustrating not to be able to use all 1.6 features...
I have seen some people complaining that Java applets crashes their browser (apparently on Unix systems) but it is more an issue with a minor number of browsers/systems than anything else.
And as pointed out, startup time of a Java applet is quite longer than for Flash (although some big Flash games are slow to load too).
Now, I have seen a number of Processing applets, like the notorious Webpages as graphs, most of them load quickly: lot of the power is already on the hard disk of the user, in the extensive Java library. Processing generates quite lightweight jars, while lot of Flash applets must include foreign libraries... or reinvent the wheel!
Some previous postings are obsolete in regard to comments on ActionScript. ActionScript3. became available in the Flex 2 time frame, i.e., January 2007 when Flex 2.0 and Flash player 9 shipped.
AS3 is a full blown OOP programming language comparable to Java. It has classes and interfaces, inheritance, access protection keywords for class members, constructors, statics, plus some nice things that Java doesn't have: properties, events, declarative data-binding, and closures.
By default AS3 is statically compiled, hence one declares the type of members and variables. This can be relaxed to where AS3 can revert back to dynamic typing ala JavaScript. It is less efficient at runtime, though. Sometimes when dealing dynamic data it is none-the-less useful to selectively employ dynamic classes. (A nice benefit of static type checked language is code completion in the Flex Builder IDE.)
Much of Flex development is accomplished using MXML. This is a declarative XML-based DSL for Flex. MXML gets compiled into ActionScript3 code, though. So what you do in MXML is equivalent to AS3 imperative coding, but can often be more concise, clearer, and more appropriately structured with respect to the underlying graphical Flex form it represents (i.e., MXML is good for coding the views of the MVC pattern).
The bottom line is that ActionScript3 programming of Flex is easy and natural for a Java or C# programmer to learn. The language is not at all the issue. The power of Flex comes in becoming intimate with the Flex SDK and the myriad capabilities found there.
Not an exact answer, as it would be very opinionated, just sharing my experience...
In a recent project, where we were building a WAI compliant site, we were asked to avoid flash objects as accessiblity was a major issue. Applets on a different note don't go very well with most web developers ;). One reason might be the differences in the paradigms of Rich UI vs. web UI.
However, we found applets to be irreplaceable (not speaking for .NET and ActiveX controls) when client side monitoring was needed. The application uses SmartCard based authentication and applets are loaded into browser to listen for client side events (card removal) and alert the server to end session.
In this context I tend to feel that Flash is meant to be eye candy (view) where as applet though designed to be versatile, takes the role of model on client side. It is to be noted that both applets and flash consume CPU cycles on client machine, hence were traditionally suited for tasks involving lengthy computation. Calculators, Report generators, Trend illustrators, Astrological chart generators (yes) and other tasks where data can be fed by user and are results shown immediately make use of these.
A major concern involves lack of client side software (Java, flash plugins). The user experience in such cases is more than annoying.
Noticed some comments about java not updating itself. Now 1.6.0_10 is out, and it's updating itself more easily and automated than before, and you have the option of a new install method, the java kernel one. This automates the install of java components as you need them.
Some text about this: http://java.sun.com/javase/6/6u10faq.jsp
So there are changes, Sun just wakes up with the new Ceo i think. I know it's 1-2 years until this new system propagates but you can start your project and have fun when it's ready maybe. :) Who knows.
Anyway, maybe you work +500% for easy animated features than flash, but if your app is not a simple animation, then you work +500% with flash for some simple 3 line java code substitution :) Depends on your app.
I worked in Java for the last 7 years, and then I recently started on AS3 on my newest project (1.5 years and going). I love AS3 and Flash, and here's why:
The language itself is very similar to Java. The documentation at Adobe is as good or better than JavaDocs.
The AS3 language supports XML as a native type. Parsing XML in Java is a nightmare.
There are nice animation and graphics frameworks for Flash, such as papervision 3D and tweener.
If you use the Flex 3 framework and Flex Builder 3, building interfaces that look as good or better than Swing is trivial. I loved writing UIs in Swing, but designing UIs in the visual Flex Designer is like a breath of fresh air.
I'm pretty sure that there's more browser support for Flash.
Have you ever seen a Flash applet load? It has really poor usability, and makes your user click through two or three dialogs before the applet starts. Flash apps just work.
Good luck on your project!
I remember Sun's slogan so vividly... "Write Once, Run Anywhere". The idea being that since programs are compiled into standard byte codes, any device with a Java Virtual Machine could run it. Over the years, Java seems to have made it onto many platforms/devices.
Is this the intention or was it ever the intention of .NET. If so, what kind of efforts are being put forth to make this a reality?
To correct some comments by others here, .Net was ALWAYS intended to be multi-platform. That is why Microsoft separated the namespaces into "System.*" (which were platform-neutral) and "Microsoft.*" (which were Windows specific).
There is Mono which runs on Linux, Solaris and OS X. In practice .Net is still pretty much a Windows-only platform. It's not really in Microsoft's interests to push it to be WORA, on the contrary. Appearing to be cross-platform however is. A lot of people have been really paranoid about Mono on Linux. MS's supposed strategy is to first let it grow to be an important part of the Linux application platform and then release the lawyers. I wouldn't bet my future on .Net's portability.
The answer is a very shaky Yes. The moment you include an external library, the answer changes to No.
For example, Microsoft has no 64-bit JET driver. JET is used by .NET to access MS Access databases.
Any applications compiled for the Any CPU target that use MS Access databases will fail on a 64-bit version of Windows.
(This is ignoring that said applications are not portable to Mono.)
Microsoft has never made those claims but they ARE making moves in the WORA arena. Silverlight 2.0 for example will use a subset of the .NET framework and be available on Windows, Linux (through the Moonlight project), MacOS, Windows Mobile, and Nokia handsets.
As others have mentioned, the Mono project has also brought the framework to multiple environments.
To put this in context, in many people's view Java never delivered on its "Write Once Run Anywhere" promise either.
At best what you got was "Write Once Debug Everywhere" or "Write Once Looks like crap Everywhere"
The successful CLR based applications have all been written using a graphical framework that is native to the target platform.
For example the following highly successful linux applications where written using c# bindings to GTK called GTK# and not using winforms like you would expect:
Banshee - music player like itunes
fspot - photo manager
TomBoy - notes program
GnomeDo - Quick launcher and dock
Equally successful windows .net applications are not written using GTK# (even though it is cross platform) they are written using winforms or WPF.
When google came to make Chrome they didn't try to use a cross platform GUI framework, instead they choose to use native GUI frameworks on each platform. Why? because that way the application, fits properly into it's environment, that way it looks, feels and acts like its native to the operating system its on.
Basically when you try to have write once run anywhere you have to make serious compromises and what you end up with is something that doesn't really work right anywhere.
The industry has largely given up on the lofty goal of write once run anywhere, as a nice idea which didn't work out in practice.
The best approach with mono/.net is to share your lower level binaries and to use a native gui framework on each target platform. GTK# on linux, winforms or WPF on windows, CocoaSharp on Mac. This way your application will look and feel like a native app.
With Mono we're getting pretty close, and with SilverLight we're allready there.
I don't think the official "intention" of .NET was WORA. I think that you could safely say that .NET was designed so that it would always run on future MS OS's. But there is nothing that precludes .NET from running on other platforms. Mono is an example of an implementation of the .NET runtime for an OS other than Windows.
Yes, this was a goal of .NET although I don't think it had the same emphasis as it did in Java. Currently, the only effor that I know of is the Mono project that is creating a version of the CLI which runs on Linux.
Interestingly enough, Silverlight actually has a slimmed down version of the CLR which can run on both Windows and Mac, which allows the same Silverlight app to run on both platforms unchanged.
It's theoretically possible, since the CLR (.Net's "virtual machine") complies with an open standard (the CLI). The question is what other implementations there are of that standard. Mono is another work in progress, but it's the only other one I know of.
I think that the idea with .NET is that it is a "Write Once, Run Anywhere (that Microsoft chooses)". However, the Mono project is slowly changing the situation.
It will never be supported on as many platforms as Java, IMHO.
The only effort is Mono, not sponsored by Microsoft.
Check here on SO and on the official site
In theory, yes. .Net Assemblies are bytecodes, which are converted to native code upon startup, using a JIT ("just-in-Time") compiler.
In practice, there aren't many platforms beyond Windows which have a .Net JIT compiler. There's one for Linux, called MONO.
Don't know about Mac, Sun etc...
Theoretically, the language is designed to be compiled into bytecode like Java which is interpreted by the Common Language Runtime, a mechanism that also allows several languages (not just C#) to work together and run on the .NET framework.
However, Microsoft has only developed the CLR for Windows. There are other non-MS alternatives being developed, the most prominent being Mono, a CLR implementation or a number of platforms (see the link).
So in theory yes, in practice - we'll see.
Yes and no. Parts of the .NET environment are standards and could be openly adopted.
For example, the runtime (CLR) has a portable version called Mono which is multi platform, open source and is used by (for example) Second Life.
The intention, or at least the pitch, was for this to be the case. The reality is that .NET can't really run on other platforms. The only major exception is Mono, which is an open source project. It's essentially a rewrite of the .NET runtime (the equivalent of the java virtual machine) that works on Linux, Solaris, Mac OS X, Windows, and Unix.
It's been fairly successful, but it's not officially supported.
If you're thinking of getting your monolithic Acme corp employer to adopt .Net and Linux, forget it. Realistically, with .NET, you're on Windows machines, period.
Yes, .NET has the Common Language Runtime (CLR) which is the .NET equivalent to the JVM. Microsoft does not support it on as many platforms as Java but with the help of the Mono project it is possible to achive cross platform applications with the usual caveats.
Bear in mind that .NET is more than just the CLR. It is a whole platform.
Since .NET is only available (officially) on Windows, then not, it isn't write one, run anywhere. However the Mono team are making a good go at helping spread .NET beyond Windows, but they are always way behind the official stuff.
I don't think that it was the original plan, for Microsoft, to create runtimes for every platform and device, but they encouraged this by using a documented (?) intermediate language.
Multiplatform was of course in the vision.. right now mono does a good job of implementing the runtime for other os.
Mono
Short answer -- no, Microsoft only supports MS operating systems (including Windows Mobile) for .NET.
Long answer -- there are public open-source projects to replicate the .NET framework for linux and other OSs, notably Rotor and Mono. They don't support everything, but you can deploy a lot of .NET code, including silverlight.
That depends on your definition of "Anywhere".
There are several flavors of Java virtual machine and of .Net framework.
And most of the time you can't just write code for a desktop vm/framework and expect it to run on a mobile phone one.
So. in a sense, even Java is not really pure "Write Once, Run Anywhere".
It is true, however, that Java's VM is currently running on several operating systems while .Net framework runs only on Windows devices.
There is one interesting initiative called "Mono" which offers .Net support on Linux, Solaris, Mac OS X, Windows, and Unix. Read here: Mono Site
dotNet can be, because of the CLR which is similar in function to the JVM.
But i dont believe MS had any intention of it being.
http://www.mono-project.com/Main_Page
might be useful, but its not a MS product.
Btw, much like how the wide spectrum of j2ee containers cloud the WORA concept for j2ee apps, ASP.NET apps running on anything besides IIS wouldnt really work the same across disparate platforms.
I don't think this was ever really a design goal of .NET - Microsoft has no particular interest in people writing software for non-Windows platforms ....
However, there is The Mono project (http://www.mono-project.com), which is "an open development initiative sponsored by Novell to develop an open source, UNIX version of the .NET development platform."
It was most assuredly meant to be WORA. It's just MS figured Anywhere and Everywhere would be Windows by now. Who knew Linux and the MacOS would still be around. But judging by all the Macs at the PDC, I guess they were either half right or half wrong!
If WORA was really an original goal, then I guess we'd see .NET implementations on all the major platforms by now, fully supported by Microsoft. I seem to recall that at the time Sun was shouting WORA from the rooftops, Microsoft's riposte was "Write Any (language) Run on One (platform)" (WARO:-). As somebody else mentioned, I think they've always been firm backers of WORASLAIW (Write Once Run Anywhere So Long As Its Windows)
As you point out, they seem to be changing tack a bit with Silverlight to try and get a piece of the Flash/Flex action now that the battlefield has shifted significantly away from the desktop and towards the browser.
But it IS multiplataform Win9x/WinNT/Mobile
Given responses from others I'm still unclear as to whether it was an actual intention of Microsoft to have .NET be a WORA initiative. The only way to really know I guess is to have somebody from the Microsoft .NET team chime in on this.
Since we cannot definitively know the original WORA intentions of .NET we can point to efforts that are attempting to make this a reality (as previous answers have talked about).
[Mono](http://en.wikipedia.org/wiki/Mono_(software))
This effort is an initiative happening outside of Microsoft.
Mono is a project led by Novell (formerly by Ximian) to create an Ecma standard compliant .NET compatible set of tools, including among others a C# compiler and a Common Language Runtime. Mono can be run on Linux, BSD, UNIX, Mac OS X, Solaris and Windows operating systems.
Silverlight
This effort is being heavily pursued by Microsoft. Silverlight 2.0 implements a version of the framework that is the same as .NET 3.0 and seems to be an attempt to successfully deliver the framework to multiple platforms through the browser.
It is compatible with multiple web browser products used on Microsoft Windows and Mac OS X operating systems. Mobile devices, starting with Windows Mobile 6 and Symbian (Series 60) phones, will also be supported.
While it does not specifically address bring functionality to GNU/Linux there is apparently a third-party free software implementation named [Moonlight](http://en.wikipedia.org/wiki/Moonlight_(runtime)).
This seems to be what we currently know, but as stated earlier, it would be very helpful if somebody from the .NET team could pitch in on this one to properly clarify if WORA was in fact an original initiative.
If Microsoft were serious about dotnet on other non windows platforms they would have released the class libraries for reuse by others ajoiding the need to rewrite the same libs again. Sun on the other hand has done this meaning less barriers are present ifnone wishesto port to another platform. Natually with java one still needs to write a vm and do the native stuff but it helps avoid a headache that is reimplementing the entire class library. The standardization of the language wS a marketing ploy to grab jon technical folk. A language without libs is worthless. Try doing your next project withnknly the prjkitive types ... That's right write your own string class etc and tell me how helpful a standardiSe language is without any libs available...
I think the idea was to create inter-operability between the different programming languages, not WORA.
.Net Core makes .Net "almost" Write Once Run Anywhere.
But there are subtle differences -
.Net Core is not really .Net
With .Net Core, you write once but build multiple times, once for each specific target OS. Whereas in Java binaries are built once and can be run on any supported OS.
dotnet build --runtime ubuntu.18.04-x64