Related
Is the DVM an interpreter or a compiler? Why did google have to come up with the DVM when there is already the JVM? Can the JVM not be used in mobile platforms? If not why not?
Is the DVM an interpreter or a
compiler?
There's a tool called dx that converts your java bytecode to a dex file. So, you compile with java to create a java bytecode (a class file) and a dx tool converts these bytecodes to a .dex file (executable).
Why did google have to come up with
the DVM when there is already the JVM?
Dalvik is optimised to run on mobile devices or devices with low memory requirement. Dalvik VM takes less space to run compared to the JVM.
One important factor is LICENSE. If Google had to go to J2ME, the application had to be licensed, etc and Google wanted to avoid being licensed.
Also a quote from #leo's - Is Dalvik the better J2ME?:
As J2ME is not really a strong
framework, you have a single
programming language, but it's up to
the vendor which functionality he
likes to integrate, every single phone
is different. That makes porting J2ME
to a real pain.
3)
Can the JVM not be used in mobile
platforms? If not why not?
At the present moment, no as it requires resources (that's available on PC) to run. Also, it's a stack machine, so it uses "instructions to load data on the stack and manipulate that data, and, thus, require more instructions than register machines to implement the same high level code" (source).
We can expect future mobile/portable devices to be able to have the processing power, storage capability and security features to run the JVM, but for now, Dalvik is king! :-)
Hope this helps.
DVM = Interpreter wiki
Dalvik is very optimized and has different architecture to support Android features. Do look at the wiki link above you will have answers for everything.
JVM can be used in mobile platforms. Infact, J2ME is based on JVM.
Is the DVM an interpreter or a
compiler?
Given that the version of Dalvik that shipped with 2.2 has just-in-time compilation, the answer is "yes."
Why did google have to come up with
the DVM when there is already the JVM?
Can the JVM not be used in mobile
platforms? If not why not?
When you say "the" JVM, I'll assume you mean Sun's* JVM. There's no reason why it can't be used in a mobile platform, and it has been. ("Mobile" being a very broad term.) However, that particular implementation is not ideal in every environment, and Java was always intended to have many ways to run its bytecode ranging from VMs on desktops to silicon that runs it directly.
Exactly what drove the decision to implement Dalvik is a question only the people who wrote it can answer, although it may have come down to licensing or having the ability to fine-tune it as they pleased. In general, though, Dalvik's more compact executable format (DEX) makes it better suited to environments where on-board memory is precious as was the case with early Android devices. Its register-based implementation may also provide better compute performance and lower power consumption than Sun's stack-based JVM on the kinds of CPUs that the OS targets.
*Sorry, Larry, no soup for you.
Some time ago I found the MJVM project. Sadly, this project has been abandoned by it author (I asked Igor via email).
I wonder if there is a (continued) open source project of a full implementation of a JVM in Java like this one.
By "full", I mean, not only to emulate mobile devices.
The Jikes RVM is probably the most prominent JVM implementation written in Java. However, its lowest level implementation simply consists of static method calls to a "magic" interface which is treated specially by the compiler and translated into native code.
The Maxine VM (developed originally by Sun Labs, now Oracle Labs) is a real metacircular VM, in which not only everything is written in Java, but there is no special-casing in the compiler going on. Even more: not only is the Maxine VM written in Java, it even runs in itself! This might sound crazy, and to be frank, I have no idea how that works, but it is based on the Klein VM (developed by Sun Labs) which does the same thing for the Self programming language.
This has some very interesting properties: since the JVM itself is part of the codebase that the JVM interprets, the same codebase that the user code belongs to, this means that it can do optimizations such as inlining across the VM boundary. IOW: it can inline VM code into the user code and vice versa. It also means that the VM itself is subject to the same runtime profiling and dynamic optimizations that – on other VMs (even including Jikes) – only the user code is, which means that the VM itself constantly gets re-compiled and re-optimized to adapt to changing loads, new classes being loaded, changing profiles, changing usage patterns and so on.
On VMs like HotSpot, JRockit, J9 and others, these optimizations are impossible, for the simple reason that the JVM only knows how to optimize JVML bytecode, but the VM isn't written in Java. But even in Jikes, this is not possible because, while the VM is written in Java, it gets statically compiled to native code before it runs, and the code of the VM itself is not part of the code that the VM "sees".
The Squawk VM is also a JVM developed by Sun Labs, now Oracle Labs. Unlike Maxine, which is roughly similar to J9, HotSpot or JRockit in its target audience, Squawk is more analogous to the KVM (originally developed by Sun, now Oracle), i.e. targeted at resource-constrained embedded devices. Squawk is also inspired by Klein. Unlike Maxine, it has a small abstraction layer written in C. But keep in mind, that Maxine requires an OS to run, whereas Squawk runs without an OS. So, in a sense, Squawk is even purer than Maxine, because many parts that are not part of Maxine but part of the OS (where they are often implemented in C, C++ or other low-level languages), are actually part of Squawk itself. Device drivers, for example, are written in Java. Only a small hardware abstraction layer and I/O libraries are written in C.
Jikes RVM is a JVM written in Java, used for research and kept under active development.
JNode is a JVM + operating system written in Java that runs one a bare x86 PC or virtual. The project's SVN has been pretty inactive of late (roughly the last 6 months), but I believe there is activity in the GIT mirrors for the project.
An interesting Java JVM implementation is this one:
https://gitlab.com/neoexpert/jvm
It is able to run simple Java Programs and some advanced ones. It should also be able to run itself.
It has also a subproject which contains an JavaScript implementation of JVM which is able to run in Browser. It is very fast.
You can run the JS implementation with:
mvn clean install
cd jsjvm
./run.sh
The JavaScript implementation does have a simple JDK which contains some classes for DOM Manipulation and WebGL bindings.
I am planning to implementat the JDWP (Java Debugger Wire Protocol) for it. If it is done, you will be able to connect with a Debugger (for example from IntelliJ) and debug Java code which is running in Browser.
Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 7 years ago.
Improve this question
I always hear that Java being open-source is a big benefit, but I fail to see how Java being open-source should draw me to use it as opposed to .NET which is closed-source. This website has some Q&A sections (What is the significance of these developments to the industry? in particular) that give a little info, but is being free the only (or the biggest) advantage to Java being open-source?
Since I am a beginner, have any of you pros noticed any major difference since the change was made?
EDIT:
Please disregard the .NET part of this question, I was simply using it as a comparison. What I really care about is knowing what benefit becoming open-source has been to Java.
If you are a mainstream user, there is probably no immediate benefit for you.
However, the open-source base of Java makes it easier for people to adapt it to more niche requirements that the closed-source vendor sees no need to support. Smaller vendors (or open source projects) can come up with solutions to these special needs.
For example, Java runs on a great variety of platforms and operating systems, most of them supported by companies other than Sun (granted, that was the case even before it was open source).
have any of you pros noticed any major difference since the change was made
I like the fact that Linux distributions now include the "official" Sun JVM and JDK, rather than making you install it separately or use the "mostly-compatible" alternative implementation that was provided.
Not entirely fair to say .NET is closed source - Microsoft's .NET runtime and development tools are closed-source.
Mono is an open-source implementation of many things in the .NET world - the CLR and C# being the biggest.
The primary implementation of .NET is closed source, though there are competing open-source implementations.
The primary implementation of JVM is open source, though there are competing closed-source implementations.
The standard for Java remains entirely under control of Sun (Oracle). Others are allowed to provide input, but final decisions are up to Sun.
The standard for CLR is entirely under control of the ECMA and ISO. Microsoft is allowed to provide input, but the final decision is up to the standards bodies. If Microsoft did ignore their decision, it's open to question whether the standard would remain relevant.
The improvements to OpenJDK since it was open-sourced have been immeasurable, here is just a few:
The Zero project, contributed by Redhat, has ported Hotspot to many new platforms like PowerPC (32 and 64 bit), IA-64, ARM and zSeries, and made future ports to other platforms much easier. The Shark subproject has also given it better performance on some of those platforms
The OpenJDK has been ported to new operating systems, such as Haiku and BSD
Many bugs have been reported and fixed by individuals and companies
Apple has joined the OpenJDK project and a MacOS port is in the pipeline
So has IBM
Various innovative projects, such as IcedRobot have become possible
OpenJDK jtreg tests are now available to other Java implementations
Some of the direct benefits to the average Java programmer are:
You can investigate and fix bugs in the JDK source code
You can build custom versions of the OpenJDK (eg. strip it down to make it smaller)
You don't need to pay license fees to ship OpenJDK on embedded devices
Java and .Net are both standards for which anyone can write an open-source implementation. .Net 3.0 just happens to have no complete open-source implementations.
Regardless of openness, the difference for you (and the reason many people choose Java at all) is portability. There are far more implementations of Java, and most are closed.
Java can create apps for cell phones. Java can create web apps. Java runs on Mac. Not .Net.
Sun is just advertising the simplification and standardization which a common open-source core may provide. But if you look closely at the page you linked, you'll see that it's using the future tense.
Opening up the JVM source helps in porting it to other architectures such as ARM for embedded use.
More choices. Flexibility. Java Community Process. I think mainly lower cost of ownership - Eclipse+ApacheServer+Linux - are all free.
For Java SE there are several JVM's available for running in production on x86:
IBM J9
Oracle JRockit - http://www.oracle.com/technology/products/jrockit/index.html
Apache Harmony - http://harmony.apache.org/
The one in OS X (if a Mac) which appears to be Sun with Aqua Swing.
OpenJDK
plus some custom offerings for running on a server:
Azul - http://www.azulsystems.com/
Google App Engine Java - http://code.google.com/intl/da/appengine/docs/java/overview.html
Other platforms:
Sun Solaris JVM - better scalability than x86?
(edit) GNU compiler for Java - http://gcc.gnu.org/java/ - can compile to native code on multiple platforms.
The Sun JVM has a distinct advantage with the jvisualvm program, which allows runtime inspection of running code. Is there any technical advantages of any other JVM that might make it a better choice for development and/or production?
In other words, is there a killer facility or scenario that would make any investment of time/effort/money worth it in another JVM?
(Please also suggest additional JVM's if they would be a good choice).
JRockit comes with JRockit Mission Control, which is a tools suite you can use to monitor the JVM and your application. You can download it here, it's free to use for development.
Mission Control has a lot of features that VisualVM is missing, for instance an online memory leak detector, a latency analyzer, Eclipse integration, JMX.logging to file. etc. If you want to compare VisualVM with Mission Control here are the release notes and the documentation for the latest version.
IBM J9
This is the kind of sales speech you can read or hear about J9:
IBM has released an SDK for Java 6. Product binaries are available for Linux on x86 and 64-bit AMD, and AIX for PPC for 32- and 64-bits. In addition to supporting the Java SE 6 Platform specification, the new SDK also focuses on, Data sharing between Java Virtual Machines, Enhanced diagnostics information, Operating system stack backtraces, Updated jdmpview tool, platform stability, and performance.
Some would say that the IBM SDK has some advantages beyond speed, that the use and expansion of PermGenSpace is much better than in the Sun SDK or GCJ (not a big deal for client applications, but heavy lifting J2EE servers, especially portal servers, can really cause the Sun JDK heartburn). But, according to this paper comparing Sun vs IBM JVM GC, it turns out that memory performance depends mostly on the application and not so much on the VM.
So, while it's true that the IBM JVM is well known for its troubleshooting features (more advanced than Sun's JVM), I'm not convinced by the differences at the GC level.
And Sun's JVM has a big advantage over IBM, at least on Solaris: DTrace providers. Actually, I've been mainly working with Weblogic on Solaris so Sun' JVM has always been the natural choice.
Oracle JRockit
I did some benchmarks of BEA/Oracle JRockit some years ago and it was indeed a fast VM and it was then supporting bigger heaps than Sun's VM at this time. But it has some stability problems which is not really good for production. Things might have changed since then though.
Apache Harmony
I might be wrong but, to me, Harmony is made of code donations from IBM (benefits: the community is doing maintenance) and I don't really see why I should consider Harmony rather than IBM J9.
Apple's JDK
I never had to use Mac for production so I can't really answer. I just remember Apple needed some time to bundle Java 6, and I don't know why. This is maybe not rational but this makes me suspicious.
OpenJDK
I know that some vendor are offering production support (e.g. RedHat with RHEL 5.3+, see this blog entry) for OpenJDK so it might be an option for platforms not supported by Sun. However, unless someone can tell me what makes OpenJDK work better than Sun's, I think I'll install Sun JVM on supported platforms.
So to me, the choices are actually: Sun's JVM unless I've to run some Websphere stuff, in which case I'd choose IBM J9. But to be honest, I've never faced a situation that I couldn't solve on a Sun's JVM and that could have justified (temporary) swapping to IBM' one so I can't actually tell if the troubleshooting features are that nice. But I admit that I may suffer from a lack of knowledge of IBM's JVM.
Some applications, like financial and computational science would benefit greatly from hardware implementations of decimal floating point. IBM has rolled out a series of processors (POWER6, the z9 and z10 mainframes) which implement the IEEE 754-2008 decimal floating point standard. The latest IBM JDK can use hardware acceleration for BigDecimals.
To allow developers to easily take advantage of the dedicated DFP hardware, IBM
Developer Kit for Java 6 has built-in support for 64-bit DFP through the
BigDecimal class library. The JVM seamlessly uses the DFP hardware when
available to remove the need for computationally expensive software-based decimal
arithmetic, thus improving application performance.
It's a very fringe case, but if you have a z10 mainframe handy and want to use its decimal floating point unit in Java, then the IBM JVM would be a better choice than the Sun JVM.
-- Flaviu Cipcigan
The typical feature/scenario that you should look at is performance and speed.
No matter what the white papers say, ultimately you need to benchmark and decide for yourself.
I am biased towards IBM, because I worked there a few years ago. I didn't personally deal with jvm development, but I remember that the emphasis of the jvm development group was on the following points:
Proprietary garbage collection optimizations. This includes not only faster GC, but also more configuration options, like GC for server and client. This was before Sun offered similar options.
Much faster (x10) native performance with the JNI interface. This was particularly important at the time when Eclipse/WSAD began to gain traction and swt was heavily used. If your app uses JNI a lot, then I think it's worth while for you to benchmark the IBM jdk against the Sun jdk.
Stability and reliability. I think this is only relevant if you buy commercial support from IBM, like SLA for a service tier (WebSphere and db2, clustered environment, etc.). In this case, IBM will guaranty the stability of their offering only if you use their jvm.
Regarding OpenJDK, I recommend that you look at this history of OpenJDK. My understanding is that OpenJDK 7 will be almost identical to Sun's jdk 7, so the performance is very likely to be identical. The primary differences will be licensing, and small components like webstart.
Oracle's jvm is useful if you want to run java code from within your database (via stored-procedure). It includes some optimizations that help the db run faster in this scenario.
As others have said, Sun has been catching up on their competitors. I think that in the 1.4 days the differences were much more noticeable, but no so much today. Regarding jvisualvm, other vendors also offer similar tools, so I don't think that is an issue.
Finally, there is one other metric (albeit a bit controversial) to indicate how serious are those vendors about their VM's. That is the number of related patents that they issue. It might be useful if you need to convince your boss, or if you like to read patents :)
Patent search: ibm and java - 4559 patents.
Patent search: oracle and java - 323.
Not strictly a JVM, but still a Java implementation: gcj. It has the advantage of supporting many processors, so if you target one of the embedded processors, gcj may be your only choice. Plus, since it is a true compiler (not just a JIT), you save the overhead of JIT compilation (both in memory and cycles) on the embedded target.
Back in the Java 1.4 days my team used the IBM JVM for a high-volume, message-based system running on Linux. Why did we do this? Because we benchmarked the different JVMs! JRockit was actually the fastest, but it would occasionally crash, so not so great for production.
As always with these things, measure it!
A few years back (JDK1.4), different JVMs had different advantages:
the IBM JVM was able to do heap dumps (programatically, on signals, or on OOM), and the heaproot utility was very useful to track memory leaks (less intrusive than profilers). No other JVM had this.
JRockit had many useful options that the Sun JVM didn't have, parallel collection. It was also (much) faster (and more stable than the Sun VM).
Today, the Sun one has these features, but I'm sure there are others.
Speed could be one. Garbage collection strategies another.
If you're using WebLogic, some bugs in the Sun JVM may lead to bugs in WebLogic. These bugs are more likely to be solved faster in JRockit.
From what I've been told, the main difference with Sun's JVM and IBM's JVM is in the actual garbage collectors, IBM's garbage collector(s?) are much more configurable than Sun's and are made only the business world in mind. Additionally IBM's JVM can tell a lot more than "I just crashed, here's my heapdump" in error situations which is obviously important in the business world which is the main living space of IBM's JVM.
So assuming I haven't been lied to, I'd say that IBM's JVM should be used when doing memory-intensive things in business software which relies on aggressive or otherwise highly tunable garbage collection.
In my own experience and at face value, I see simplicity in the IBM GC design. Sun's various and new GCs are excellent no doubt and offer a host of tuning options at minute levels, but even in some of the most active web apps I know that handle heavy/aggressive new objects and keep a lot in the heap for cache I rarely see GC ever exceed 1% even trying to keep the footprint low. Sure we could probably tune it better but there's a diminishing return.
I have had much more of a challenge in the exact same applications running IBM's JDK. In particular having issues with pinned clusters and having to tune -Xk.
Now I could mention about a dozen items that both IBM and Sun should implement for the killer JVM but not the scope of your question I presume :)
Incremental garbage collection and very small runtime size for realtime embedded systems is the only thing that would really matter enough to warrant chancing less stability or platform support. There was some jvm with this in mind but I forget its name now.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
How much less libraries are there for Mono than for Java?
I lack the overview over both alternatives but I have pretty much freedom of choice for my next project. I'm looking for hard technical facts in the areas of
performance (for example, I'm told Java is good for threading, and I hear the runtime code optimization has become very good recently for .NET)
real world portability (it's both meant to be portable, what's Catch-22 for each?)
tool availability (CI, build automation, debugging, IDE)
I am especially looking for what you actually experienced in your own work rather than the things I could google. My application would be a back-end service processing large amounts of data from time series.
My main target platform would be Linux.
Edit:
To phrase my question more adequately, I am interested in the whole package (3rd party libraries etc.), not just the language. For libraries, that probably boils down to the question "how much less libraries are there for Mono than for Java"?
FYI, I have since chosen Java for this project, because it seemed just more battle-worn on the portability side and it's been around for a while on older systems, too. I'm a tiny little bit sad about it, because I'm very curious about C# and I'd love to have done some large project in it, but maybe next time. Thanks for all the advice.
Mono does a better job at targeting the platforms I want to support. Other than that, it is all subjective.
I share C# code across the following platforms:
- iOS (iPhone/iPad)
- Android
- The Web (HTML5)
- Mac (OS X)
- Linux
- Windows
I could share it even more places:
- Windows Phone 7
- Wii
- XBox
- PS3
- etc.
The biggie is iOS since MonoTouch works fantastically. I do not know of any good way to target iOS with Java. You cannot target Windows Phone 7 with Java, so I would say that the days of Java being better for mobile are behind us.
The biggest factor for me though is personal productivity (and happiness). C# as a language is years ahead of Java IMHO and the .NET framework is a joy to use. Most of what is being added in Java 7 and Java 8 has been in C# for years. JVM languages like Scala and Clojure (both available on the CLR) are pretty nice though.
I see Mono as a platform in it's own right (a great one) and treat .NET as the Microsoft implementation of Mono on Windows. This means that I develop and test on Mono first. This works wonderfully.
If both Java and .NET (Mono let's say) were Open Source projects without any corporate backing, I would choose Mono over Java every time. I believe it is just a better platform.
Both .NET/Mono and the JVM are great choices, although I would personally use some other language than Java on the JVM.
My take on some of the other comments:
Issue: Performance.
**Answer: Both the JVM and the CLR perform better than detractors say they do. I would say that the JVM performs better. Mono is generally slower than .NET (though not always).
I personally would take ASP.NET MVC over J2EE any day both as a developer and an end-user. Support for Google Native Client is pretty cool too. Also, I know that poor GUI performance for desktop Java apps is supposed to be a thing of the past but I keep finding slow ones. Then again, I could say the same for WPF. GTK# is plenty fast though so there is no reason they have to be slow.
Issue: Java has a larger ecosystem of libraries available.
Answer: Probably true, but it is a non-issue in practice.
Practically every Java library (including the JDK) runs just dandy on .NET/Mono thanks to IKVM.NET. This piece of technology is a true marvel. The integration is amazing; you can use a Java library just like it was native. I have only had to use Java libraries in one .NET app though. The .NET/Mono ecosystem generally offers more than I need.
Issue: Java has better (broader) tools support
Answer: Not on Windows. Otherwise I agree. MonoDevelop is nice though.
I want to give a shout-out to MonoDevelop; it is a jewel. MonoDevelop integrates most of the tools I want use including code completion (intellisense), Git/Subversion integration, support for unit tests, SQL integration, debugging, easy refactoring, and assembly browsing with on-the-fly decompilation. It is wonderful to use the same environment for everything from server-side web to mobile apps.
Issue: Compatibility across platforms.
Answer: Mono is a single code-base across all platforms, including Windows.
Develop for Mono first and deploy to .NET on Windows if you like. If you compare .NET from MS to Java though then Java has the edge in terms of consistency across platforms. See next answer...
Issue: Mono lags .NET.
Answer: No it does not. IMHO, this is an often stated but incorrect statement.
The Mono distribution from Xamarin ships with C#, VB.NET, F#, IronPython, IronRuby, and I think maybe Boo out of the box. The Mono C# compiler is completely up to date with MS. The Mono VB.NET compiler does lag the MS version. The other compilers are the same on both platforms (as are other .NET languages like Nemerle, Boo, and Phalanger (PHP) ).
Mono ships with a lot of the actual Microsoft written code including the Dynamic Language Runtime (DLR), Managed Extensibility Framework (MEF), F#, and ASP.NET MVC. Because Razor is not Open Source, Mono currently ships with MVC2 but MVC3 works on Mono just fine.
The core Mono platform has kept pace with .NET or many years and the compatibility is impressive. You can use the full C# 4.0 language and even some C# 5.0 features today. In fact, Mono often leads .NET in many ways.
Mono implements parts of the CLR spec that even Microsoft does not support (like 64 bit arrays). One of the most exciting new pieces of technology in the .NET world is Rosylyn. Mono has offered the C# compiler as a service for many years. Some of what Rosylyn offers is available via NRefractory as well. An example of were Mono is still ahead would be the SIMD instructions to accelerate gaming performance.
Microsoft does offer a number of products on top of .NET that are not available in Mono which is were the misconception about Mono lagging comes from. Windows Presentation Foundation (WPF), Entity Framework (EF), WCF (Windows Communication Foundation) are examples of products which do not work, or are poorly supported, on Mono. The obvious solution is to use cross-platform alternatives like GTK#, NHibernate, and ServiceStack instead.
Issue: Microsoft is evil.
Answer: True. So what.
Many people offer the following reasons to avoid using Mono:
1) You should not use Mono because Microsoft tech should be avoided
2) Mono sucks because it does not let you use every technology that Microsoft offers
To me, it is clear that these statements are incompatible. I reject the first statement but will skip that argument here. The second statement is true of all .NET alternatives.
The JVM is a great platform and the explosion of JVM languages is awesome. Use what makes you happy. For now, that is often .NET/Mono for me.
Well....Java is actually more portable. Mono isn't implemented everywhere, and it lags behind the Microsoft implementation significantly. The Java SDK seems to stay in better sync across platforms (and it works on more platforms).
I'd also say Java has more tool availability across all those platforms, although there are plenty of tools available for .NET on Windows platforms.
Update for 2014
I still hold this opinion in 2014. However, I'll qualify this by saying I'm just now starting to pay some attention to Mono after a long while of not really caring, so there may be improvements in the Mono runtime (or ecosystem) that I haven't been made aware of. AFAIK, there is still no support for WPF, WCF, WF, of WIF. Mono can run on iOS, but to my knowledge, the Java runtime still runs on far more platforms than Mono. Also, Mono is starting to see some much improved tooling (Xamarin), and Microsoft seems to have a much more cross-platform kind of attitude and willingness to work with partners to make them complimentary, rather than competitive (for example, Mono will be a pretty important part of the upcoming OWIN/Helios ASP.NET landscape). I suspect that in the coming years the differences in portability will lessen rapidly, especially after .NET being open-sourced.
Update for 2018
My view on this is starting to go the other way. I think .NET, broadly, particularly with .NET Core, has started to achieve "portability parity" with Java. There are efforts underway to bring WPF to .NET Core for some platforms, and .NET Core itself runs on a great many platforms now. Mono (owned by Xamarin, which is now owned by Microsoft) is a more mature and polished product than ever, and writing applications that work on multiple platforms is no longer the domain of deep gnosis of .NET hackery, but is a relatively straightforward endeavor. There are, of course, libraries and services and applications that are Windows-only or can only target specific platforms - but the same can be said of Java (broadly).
If I were in the OP's shoes at this point, I can think of no reason inherent in the languages or tech stacks themselves that would prevent me from choosing .NET for any application going forward from this point.
I actually develop in .NET, run all my tests first on Mono, and then on Windows. That way I know my applications are cross platform. I have done this very successfully on both ASP.NET and Winforms applications.
I am not really sure where some people get the impression Mono is so horrible from, but it certainly has done it's job in my cases and opinions.It is true you will have a bit of lag for the latest and greatest inventions in the .NET world, but so far, .NET 2.0 on Windows and Linux is very solid for me.
Keep in mind there are obviously many quirks to this, but most of them come from making sure you are writing portable code. While the frameworks do a great job of abstracting away what OS you are running on, little things like Linux's case sensitivity in paths and file names takes a bit of getting used to, as do things like permissions.
.NET is definitely very cross platform due to Mono based on my experiences so far.
Java actually is as cross-platform as everyone says it is. There's a JVM implementation for just about any mainstream OS out there (even Mac OS X, finally), and they all work really well. And there's tons of open source tools out there that are just as cross platform.
The only catch is that there are certain native operations you can't do in Java without writing some DLLs or SOs. It's very rare that these come up in practice. In all those cases, though, I've been able to get around it by spawning native processes and screen-scraping the results.
I think the question is phrased incorrectly. C# vs. Java is much less interesting in terms of cross-platform usage than is (a) which platforms you need to support, and (b) considering the core libraries and available third party libraries. The language is almost the least important part of the decision-making process.
Java is a better choice for Cross-Platform development.
Performance. Java and .Net have similar performance level due to the virtual machine, but JVM normally has better performance because of years and years optimization.
Library. Although this depends on your task, Java has much more open source or third party libraries available there. For server App, J2EE, Spring, Struts, etc. For GUI, although .Net provides Win32 layer API but this causes compatibility issues. Java has Swing, SWT, AWT, etc. It works in most cases.
Compatibility. This is the key issues that need to be considered when develop the cross-platform program. Two issue: first, platform compatibility. Java still wins since JDK is well maintained by single and original company Sun. Mono is not maintained by MS, so you have no guarantee yet for update compatibility. 2. Backward compatibility. Sun maintains a good reputation on their backward compatibility, although sometimes this seems too rigid and slows the pace.
Tools. Java has good cross-platform IDEs. Netbeans, Eclipse, etc. Most of them are free. VS Studio is good but only on Windows, and not cost a bit. Both of them provides good unit tests, debugs, profiles, etc.
Hence I'd suggest that Java is a better choice. As a show case, there are some famous desktop cross-platforms apps developed by Java: Vuze, Limewire, BlogBridge, CrossFTP, not to mention those IDEs. As to .Net, I have limited knowledge on such success apps.
I've been asking the same question off-late and IMHO, .NET/Mono seems to be a better option simply because Mono has a great track record for cross-platform desktop applications (as opposed to Java) and of course, Mono is improving by leaps and bounds these days.
I'm going to say Java as well. If you look at it in terms of maturity, a lot more time and effort has been expended by Sun (and others) in getting the JVM to work on non-Windows platforms.
In contrast, Mono is definitely a second class citizen in the .NET ecosystem.
Depending on who your target customers are, you may also find there is real pushback against using Mono - does Novell offer the same kind of vendor support for Mono that you would get for Java or .NET on Windows?
If you were primarily targeting hosting your service on Windows, it would make sense to be considering this choice, but since you're targeting Linux primarily, it seems like kind of a no-brainer to me.
Java was designed to be cross-platform; C#/.Net wasn't. When in doubt, use the tool that was designed for your purpose.
EDIT: in fairness, .NET was designed to work on embedded/PC/Server environments, so that's SORT of cross-platform. But it wasn't designed for Linux.
I think the answer is "it depends." Java runs on just about anything, but .NET/Mono are (IMHO) a better framework for the desktop. So I guess the answer really depends on what platforms you plan on targeting.
To add a bit more to the conversation, Java is more portable if you remain about one version behind - Java 5 still has many excellent features so you can wait for Java 6 and still have a lot of range in terms of language and libraries to develop with. The Mac is the primary platform that can take some time to catch up to the latest Java version.
Java also has an excellent standards body that intelligently grows the platform based on input from many different companies. This is an oft overlooked feature but it keeps even new features working well across multiple platforms and provides a lot of range in library support for some esoteric things (as optional extensions).
I would vote for Java being more portable than C#. Java definitely also has a very rich set of standard libraries. There is also a broad set of open source 3rd party libraries out there such as those provided by the Jakarta project (http://jakarta.apache.org/).
All the usual suspects exist for CI, Unit testing, etc too. Cross platform IDE support is also very good with the likes of Eclipse, Netbeans, IntelliJ IDEA etc.
There are other language choices too. I've become quite fond of Python, which works well on Windows, Linux, and Mac, and has a rich set of libraries.
While Mono has its share of problems I think it has a better cross-platform compatibility story especially IF you have reliance on native platform invocation.
There are not enough words on Stack Overflow to stress how much smoother it is to get something native called and executed in .NET/Mono on (at least in my experience 3...) multiple platforms vs. the equivalent Java effort.
Gatorhall do you have some data to back that up?
Performance. Java and .Net have similar performance level due to the virtual machine, but JVM normally has better performance because of years and years optimization.
Background: I'm a Windows guy since Windows 3.1 and currently a Linux user (still running Windows 7, great OS, on a VM for Visual Studio 2010 and other tools).
The point: me and a lot of users (windows, linux, etc) I know, may disagree from you. Java tends to perform slower even on a linux desktop application, ASP.NET perform's faster that java server pages many of the times. Some may agree that even non-compiled PHP performs better i several scenarios.
Java is more cross-platform? I have no doubts about this (the history back this on), but faster (not saying .NET is) not so certain and I would like to see some real benchmarks.