Related
I'm curious if there are any Java abstractions that are similar to .Net's AppDomain.
In particular, I'm curious because I've found that with our Coldfusion/J2EE server we need to restart it every few days due to a slow memory leak that we haven't been able to easily track down yet. This can wreck our long-running processes and we'd really like a way to slowly just push people to new JVMs as they age past a certain time period/memory threshold.
From my limited .Net experience I'm pretty sure that this is one situation that IIS and AppDomains are able to manage fairly seamlessly by recycling AppDomains that come under memory pressure. Please let me know if I'm way off on AppDomains helping in this scenario.
Any suggestions?
I think Yiannis's answer here is a little misleading. Simply saying "no, you can't" is not the whole story. The question is focused on unloading Java classes in a server process to remove leaky code from the JVM process without a process restart. The OP is not asking for the process-like memory isolation feature that an AppDomain gives, but the ability to unload classes in a running JVM. I say process-like, since under the hood an AppDomain is not a process, but enjoys some of the isolation aspects that a first-class process is afforded by the operating system. The isolate JSR mentioned is referring to this 'process-like' isolation. Unloading java ClassLoaders and thus classes, without cycling the OS process hosting the JVM is possible. A couple of methods are mentioned here: SO 148681. It is not trivial, or elegant to do this in Java, but it is possible.
Unfortunately, no.
The analogous concept in the Java world is the Isolate, that appeared first in the JSR 121. This was an API for a future JVM feature that would allow safe separation and communication between different applications running in the same JVM. After the JSR was published (around 2004) one research team in Sun worked in the Barcelona project. This project tried to implement the Isolation API in Sun's HotSpot 1.5 VM. After two years, they released a prototype for SPARC/Solaris. Windows/Linux versions were never released due to stability problems.
Recently, SUN has introduced a limited version of the Isolation API to J2ME, focusing of offering "multiple processes" in environments that didn't actively offer them. Recently, we also asked Sun for their status in implementing the Isolate API to standard JVMs and their response was that they plan to release a JVM with limited support. They plan to offer the ability to load/unload Isolates but without the ability to communicate between them.
Also, there has been an old reserach efford to build an Isolates-compatible JVM version, called JanosVM (java 1.1) but I doubt that it can be of any use today.
Hope this helps...
Recycling of individual JVMs on the basis of time or specific criteria such as growing memory consumption and memory use threholds is a capability of the advanced versions of the App Server I work with, WebSphere. If your App Server does not have that capability, then crafting some shell scripts to give something like that function should be doable.
This works quite nicely assuming:
a). Requests from users are sprayed around the a larger set of JVMs.
b). That all requests are stateless or there is some state replication capability. Replication is a capability of WebSphere and WebLogic, I'd guess that other app servers have the capability too.
In such environments there's no need to "slowly" move people to other servers. We just need to know that we can safely stop any one serve/JVM and that these sessions will pick up on another instance.
I recently used a Java Web Start application. I launched it from my web browser using an embedded jnlp link in the page I was viewing. The application was downloaded, launched and worked just fine. It had access to my local file-system and remembered my preferences between restarting it.
What I want to know is why are Java Web Start applications not a more popular delivery format for complex applications on the web? Why do developers often spend considerable time & energy replicating desktop functionality in html/javascript when the power of a desktop application could be delivered more easily using Java & Java Web Start?
I know that in some corporate environments, e.g banking, they are relatively popular ways of delivering complex trading applications to clients, but why are they not pervasive across the web as a whole?
(For the sake of discussion let's assume a world where: download sources are "trusted" & applications are "signed" (i.e. no security concerns), download speeds are fast (load time is quick) and developers know Java (in the numbers they know html/js/php)).
I think the reason is not security nor startup time of the app. Let's understand what's behind the scene before we find out the root cause.
Java Control Panel has settings that allow users to use the default browser's proxy settings or to override them. In other words, infrastructure teams are able to customize the Windows or OS installation images to have JVM pre-installed with enterprise proxy settings. So I believe this is not an issue at all.
Java Web Start actually caches all apps with customizable settings in Java Control Panel. Once the app is cached, the app is "installed" just like other apps. Although first time execution may be slow, the second time will be fast due to JVM's smart memory allocation technique. So start up time could be an issue but a lot of web sites (even enterprise internal) are now migrated to portal. A web portal normally contains lots of unused libraries for development purposes due to the fact that the portal itself does not anticipate what kinds of portlets are built and deployed on a specific page. Therefore, downloading a single portal page could consume up to MBs and complete a page in more than 5 seconds; this is only one page and caching helps up to 30% but there are still lots of HTML/Javascript/CSS components required to download every time. With this, I am sure Java Web Start is an advantage here.
Java Web Start does not download again if it is cached as long as the server copy is NOT upgraded. Therefore, if, e.g. a project management software like MS Project, is completed using SmartClient (similar to JWS), the information exchange between the client and server would be purely data without presentation like browser's full page refresh. Even with the help of Ajax, it doesn't eliminate full page download entirely. Besides, a lot of companies consider Ajax to be immature and unsecured still. That is why Ajax is a hot topic in the circles of developers but not within enterprise software yet. With that in mind, JWS apps definitely have more advantages such as how JWS apps are deployed and executed in sandboxes, signed, and have much more interactive GUI.
Other advantages include faster development (easier to debug in code and performance), responsive user interface (does not require Comet Servers to provide PUSH functionality), and executing faster (for sure because client computers renders GUI without translation like HTML/Javascript/CSS, and less data processing).
After all these, I haven't touched the question yet, why JWS is not so famous?
My opinion is that it is the same as Brian Knoblauch's comment, it's without awareness.
IT folks are too attracted by the hype of Web Technologies, Ajax PUSH, GWT, and all those buzz words make them bias towards the fun of using different technologies or to resolve technical challenges instead of what's really working for the clients.
Take a look at Citrix. I think Citrix is actually a great idea. Citrix allows you to build your own app farms behind the scene. There are tons of upgrade and implementation strategies you can go for without impact to client experience. Citrix deployment is extremely easy, stable and secure. Enterprises are still using it. However, I think JWS is even better than Citrix. The idea of JWS is to run apps on client machines instead of hosting tons of server farms where client machines are capable of running these apps themselves. This saves a company a lot of money!!! With JWS, development team can still build business logic and data on server side. However, without the web processing unit and let the client computers do the rendering process, it greatly reduces the amount of network consumption and server processing power.
Another example of why JWS is an amazing idea is Blackberry MDS. Blackberry apps are actually Java apps translated from Javascript. With BB's MDS studio, you use the GUI tool to build BB app GUI, coding GUI logic in Javascript. Then apps are then translated and deployed on a BES server. Then the BES server will distribute these apps to BB. On each BB, it runs a thin Java App with GUI rendering and networking capability only. Whenever the app requires data, it communicates with the BES through web services to consume services from other servers. Isn't this just JWS BB version? It's been extremely successful.
Finally I think JWS is not popular because of how Sun advertises it. BB never advertises how good their BB Java apps are, they believe clients won't even care what is it. BB advertises the benefits of using MDS to develop apps: Fast, Cost Saving, Business Return.
Just my, a bit long, 2 cents... :)
A major roadblock for Java Webstart is probably that you still need to have a JVM installed before it can even attempt to download and start your application. Everyone has a browser. Not everyone has a JVM.
Edit:
I've since acquired some hands-on webstart experience and can now add these two points:
The Deployment Toolkit script and the modularized JVM released somewhere around Java 1.6u10 make the JVM requirement less problematic since it can automatically download a JVM and the API core and start the program wile downloading the rest.
Web Start is seriously buggy. Even among the Java 1.6 releases there was one which downloaded the entire app every time, and another which downloaded it and then failed with an obscure error message. All in all, I cannot really recommend relying on such a fragile system.
I think it's mostly due to a lack of awareness. It works very well. Quite seamless. App only downloads if it's the first time, there's been an upgrade, or if the end-user has cleared the cache. Great way to deploy full-blown desktop apps that user won't have to worry about manually upgrading!
The problem with Webstart is, that you actually have to 'start' something which isn't at all that fast even with a fast connection, while with a webapp you enter the URL and the app is there.
Also a lot of things can go wrong with webstart. Maybe the intended user doesn't have the privileges needed, or the proxy of webstart is configured wrong, or something went wrong with jre dependencies or there is simply no java installed in the first place. So for the average john doe in the internet it is not at all pleasent.
In controlled environments like a company it is a good and easy solution in many cases.
I've worked on a JWS-deployed application for a few years over a user base of a few thousands and its automatic upgrades are actually a huge pain.
On every update for some reason dozens of users get "stuck in the middle". All you get is the "class not found" exception (if you're lucky), or uninformative "unable to launch" from JWS before it even gets to your code. Looks like the update is half-downloaded. Or, in other words, it does not download and apply the update atomically AND has poor caching so that relaunching the app from the same URL does not fix anything.
There's no way to resolve it other than clearing JWS cache or providing a different URL (e.g. append ?dummyparam=jwssucks at the end). Even I as a developer hit it sometimes and don't see a way around.
When it works, it works. But too often it doesn't, and then it's a huge pain for you and your helpdesk. I would not recommend it for enterprise or mission-critical use.
There is a very big issue namely that it doesn't allow for "start the program instantly and THEN check for and download any updates in the background" deployments, which is what the defacto behaviour of applications are converging to.
I consider this personally so big an annoyance that we are actively looking for another technology which provides that.
From these posts it looks like when using Web start, it is important to make a good care about the server. The "huge pain" of downloading application on every startup may be caused by incorrect time stamp delivered from the server. Here not the application but the server must be configured to use caching properly and not just to disable it. About buggy start, I am not that much sure, but it seems to me that this also may be caused by unreliable connection.
Important advantage of Web start is that it works nicely with OpenJDK under Linux. Clients of some happy developers use Windows only but my clients do not.
HTML and JavaScript, mentioned in the initial question, are lighter approaches that work fine with smaller tasks like animated buttons or even interactive tables. Java niche seems around much more complex tasks.
Java Web Start is kind a successor of Java Applets, and applets got burned around the new millenium.
But, I still think Java Applets are way better than GWT or Javascript hell.
Java Web Start vs Embedded Java Applet
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.
JavaFX is now out, and there are promises that Swing will improve along with JavaFX. Gone will be the days of ugly default UI, and at long last we can create engaging applications that are comparable to Flash, Air, and Silverlight in terms of quality.
Will this mean that Java Applets that hail from 1990's are dead and not worth going back to?
Same with Java Desktop: What will be compelling for us Java Developers to use it rather than JavaFX?
In my opinion Java Applets have been dead for years. I wrote some in the late 90s - a Tetris game during an internship to demonstrate on a 40MHz ARM Acorn Set Top Box for example. Of course I bet there are some casual game sites that have tonnes of them still, and thus it will remain supported, but active development will/has dropped off.
Java Web Start is a handy technology in my opinion. That will still work with JavaFX, it's just another library for that system.
JavaFX will give Java opportunities beyond technical tools (like SQL Developer), in-house business applications and server applications (where it excels). I think it's one of those libraries that is worth learning for any Java developer, if they can get the time. There's no arguing that user interface libraries for Java have been sorely lacking, or overly complex, for many a year.
However there's a lot of competition out there, and it is very new (which means the development tool support is very raw, compared to Flash and Silverlight). Also people don't like downloading massive runtime environments, although broadband makes it less painful than 5 years ago for many!
I think this discussion is somewhat misleading. I an no fan of applet technology either (and I have been underwhelmed by JavaFX). But the point that this thread is missing is that, unless I am mistaken, JavaFX is built on top of applet technology. They are not competing or mutually exclusive. See these articles here and here.
It could be that the confusion is somewhat intentional on Sun's part as they do not want JavaFX and applets to be mentioned in the same sentence, since Applets had so many problems.
Java Applets are not dead.
They had a bad history, for several reasons:
Most platforms had bad browser plug-ins for the entire 90s, moving into the 2000s, and this gave Applets (and Java, to some extent) a reputation for slowness and large downloads.
The actual Applet platform created a new VM for each applet, which further created sluggishness, especially in the startup of an Applet.
many Applet developers weren't conscientious about minimizing the size of the jars they pushed down, even Further creating the impression of sluggishness
The improvements which bring JavaFX also bring improvements to the Applet (they are one and the same). VMs can be shared and caching is better than before. In addition, higher average user bandwidth can help even poorly designed applet deployments startup quickly. If you look along the axes of install base and platform power, the Applet is still pretty high up, if not the top, in my opinion.
JavaFX is cool, but it requires an additional runtime, and for many parts of it is just syntactic sugar on top of the Applet platform. Almost any problems Applets have today are shared by JavaFX for this reason
Java Applets died not because of the concept of an applet, but because the JRE plugin for web browsers was abyssmal.
In fact, Flash proved that there is a role for in-line interactive content.
JavaFX is a new way of programming rich internet applications - essentially equivalent to Java applets or Flash content. The new JRE runtime (1.6.0_10, aka "Update 10") includes lots of features that make running Java in the context of a browser much more palatable.
JavaFX != Java Desktop. The two are quite different, and each have a place in a developer's toolbox.
Actually, Java applets are a nice technology which could have been as ubiquitous as Flash, if only Sun didn't lose the PR and technology war with Microsoft.
Microsoft was pushing DirectX controls at a time, and leveraging IE market share against applets. I remember doing some benchmarks then: Java applet of 3 MB (which was large), loaded from local disk (to take network load times out of equation), took around 5 seconds to start in Opera. The same applet somehow took about 2 minutes to start in IE.
So, it wasn't that technology sucked; it wasn't that applets were slow because they were too big; they were slow because the dominant browser at the time deliberately made them slow. :)
I guess that JavaFX is Sun's attempt to revive a lot of ideas from applets, at a different time and in a different market.
Though this might eventually be true , currently JavaFX lacks controls , no mobile devices support and other lacunae which makes it 'not there yet'
Will this mean that Java Applets that hail from 1990's are dead and not worth going back to?
JavaFX and associated changes are an attempt to revitalize the applet space - applets were always dogged by poor plugin implementations and flakeu`y bridges into the browser. That's been improved - though still needs more work - but at last Sun has recognized it needed work and has done something about it. Applets are better positioned than they have ever been. Of the competition you mention - Flash, Air, and Silverlight - I think you missed out the key competitor - the browser/javascript - the browser makers are also addressing key platform weaknesses - javascript performance, ability to do arbitrary drawing ( ie canvas etc ). For low-end requirements I think a pure play browser approach is going to win out - for higher end graphics - JavaFX has a chance.
Same with Java Desktop: What will be compelling for us Java Developers to use it rather than JavaFX?
As a big developer of Java Desktop apps, one of the things that's missing is a decent set of basic widgets and the time to play! It needs a killer table implementation - you can embedded swing but kinda what's the point. Now I could write my own by that's not really where I'm adding value in my kinda of job.
1 - Will this mean that Java Applets that hail from 1990's are dead and not worth going back to?
With the update to the Java plug-in - all applets, not just JavaFX-based applets get the improved user experience and performance. That being said - I don't think there are many (if any) killer applets out there. If there were - JavaFX would never have been needed.
2 - Same with Java Desktop: What will be compelling for us Java Developers to use it rather than JavaFX?
If you are building GUI applications and want to run it in Java - in particular across multiple platforms (e.g. desktop, applets and mobile) as well as make it easier to work with someone who has actual Photoshop/GIMP skills - JavaFX is your best choice because it was designed explicitly for that type of process. However, remember JavaFX can call Java code and it can also make remote calls (either getting back XML or JSON). I think the most likely integration point will be to use JavaFX for UI and caching of results but all of the heavy coding logic will be on the server. Where it can be written in Java or .NET or assembler if you can get your assembler to emit XML or JSON :).
I agree with the others, Java Applets already died. JavaFX could possibly fill that void. However, I just don't see it replacing Java Desktop any time soon. It's the same thing as saying web apps will replace all desktop apps. Some people do believe that, and I agree that web apps will grow in popularity, however, desktop apps will continue to have a place for quite awhile.
We cannot easily write applets down as there are way too many good code on a web. Lots of it was written by people who are not specialists in software development but are specialists in various high end areas that they tried to explain and illustrate with the help of Java applets, the top technology at that time. They may not have time to learn new language and rewrite they work any. Many are not active for years.
I also see Java applets as more appropriate for community projects that are based on server side builds and code reviewing. Various fancy user friendly tools can make development of web components fast and easy but the result is either not human readable at all or very difficult to review.
We have recently launched the Ultrastudio.org project that still relies on Java applet technology. I was thinking a lot about putting more languages and platforms but at the end was forced to conclude that it is either less secure or otherwise way more complex to do.
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 11 years ago.
Why would you choose java over others? Why did you choose java to program your application?
Please include what you are using java for (desktop application/ web application/ mobile).
Excellent tooling: IDE, CI, etc.
Vast array of 3rd party libraries.
Huge amount of documentation available.
Large pool of developers available.
Platform ubiquitous.
Excellent performance.
Excellent specification.
Sturdy garbage collection.
Managed memory.
Native threads.
Choice - implemented by multiple vendors.
I have used Java to build various middle-ware products: Inventory mgmt; CMS; chemical registration; etc.
One of the nice things about Java is that everyone knows it. Of course, now that I've said that, I'll get 80 comments from people claiming to have never learned the language. Be that as it may...
Like it or not, Java is the closest thing to a lingua franca (the idiom means "common language") we have in the industry today. Just about every has either used Java at some point, or (more commonly) is actively using it now. That sort of ubiquity can be extremely attractive to some companies, particularly those reliant on consultants. If you start a project in Java, you're pretty much guaranteed to be able to find talent to maintain the code base for years down the road.
On a different tack, Java is an excellent language for developing cross-platform desktop applications...it's just that nobody knows it. Most of Java's dominance is on the server side coupled with a little bit of love from the J2ME crowd. However, if you objectively consider Swing in Java 6uN, it's hard to find a better tool for the job. Don't get me wrong, I see that it has its flaws, but many of those have been fixed in recent releases. Most of the issue now is mindshare: everybody knows that Java is slow and ugly (neither of which is strictly true anymore). The other problem is that Swing is very much a cross-platform UI toolkit. This means that it is inherently much harder to create professional UIs in Swing than in Cocoa or even WinForms.
Finally, a really great reason to pick Java (as opposed to .NET or Objective-C) is the ecosystem. Other answers have mentioned libraries, which really deserve a significant spotlight; but I'm thinking specifically of the rising language diversity. If you write an application in Java today, you can seamlessly transition to Scala at any time. You also have the option to do scripting in Groovy or JRuby, not to mention taking advantage of the powerful concurrency abstractions in Clojure. Because of its portability and high-level nature, the JVM is increasingly the preferred target for language compilers and interpreters (even more than the CLR). Java is really at the center of that nexus, not really benefiting directly from the vast cloud of languages which swarm around it, but certainly deriving value from all of the interoperability, present and future.
My reasons for prefering Java over other programming languages at this time are:
price - it's free
performance - really fast these days thanks to the HotSpot JIT compiler
effectiveness - lots of power with rigorous features like type-safe, sand-boxed, etc.
OOP capability
very good, well-thought out exception handliing; C++ exceptions are the opposite!
portability - it runs on almost everything
tool availability - awesome IDEs like Eclipse & NetBeans are free, as are web servers like Tomcat and application servers (JBoss, Glassfish, Geronimo, etc.)
flexibility - does graphics, desktop GUIs, web user interfaces - all kinds of things in all kinds of runtime environments
aptness - many enterprise apps today have to support HTML, SQL, and XML - Java has good support for all of them built in and you can get third-party libraries for free that make this even easier/better
well-supported - Sun keeps adding improvements and fixing thing going one or two versions back
forward compatibility - unlike something like VB which undergoes wrenching change in its syntax every couple versions or so, Java's syntax and semantics seem about 99.9% upward compatible from version to version
I have been writing programs in Java for over a decade and I am pretty satisfied with it. I have used other languages for almost two decades before that. So I am not biased by describing the one thing I know - it is one of many languages I know intimately.
When upgrades to the JDK/JRE come out, I look the documentation over to see what is changed. Sun is good about telling/explaining this. I have never had an extremely rough time porting from one JDK to the next.
When I have switched from one OS to another as my main OS at home or at work, it has not caused a problem for the Java applications I write - or the tools I use, generally. The one exception is Borland JBuilder, which some Borland marketing or technical genius decided to frequently stop supporting. Eclipse and Netbeans run terrifically on the Mac and probably always will. I have used Java on:
MS-Windows 95, 98, NT4, 2000, XP
Sun Solaris/SunOS Unix
IBM AIX
Mac OS X
Linux
Motorola cell phones (MIDP, CLDC)
Palm Pilot PDA
Java VMs (virtual machines) are everywhere! They are in:
web browsers
cell phones
PDAs
desktop computers
web servers
application servers
I have written programs on all of these. All you have to do is get an IDE with the right plugins, get the API documentation for the target environment you want, and start programming.
The GUI programs I write actually do look & work correctly on different platforms! I cannot tell you how long other vendors promised to do and how often/long they have failed. Just look around, some still exist.
Sun promised this in Java 1.0 and they sort of delivered it with AWT. However, the abstract windowing toolkit used native GUI components and the differences between these components (which followed no unifying standard at all) were too great to get same/nice look/behavior on all platforms.
Sun delivered very well upon this portable GUI promise when the Swing GUI API was delivered a decade ago, back in December 1998.
1) Very good and free documentation
2) Very good developer commercial and free tools
3) good certification and training resources
4) good runtime and free tools
5) good profiling and monitoring tools
6) very good support options from various companies
7) very good open source community with huge amount of libraries
Things not yet mentioned:
Cross-platform Desktop Application, even with sophisticated GUI
bunch of tools
static typing (see GWT)
error messages at compile time
very clear error messages
Java provides a very rich API right out of the box and hands-down produces the most portable applications since there is a Java VM for almost every platform.
BTW: I haven't used Java since I left college since I work for a Microsoft shop, but I can't think of a single thing I can do in C# that I can't do in Java, whether it be enterprise applications, web applications, or desktop applications.
Portability is the key to java. I know that a program that i am coding will run on any system, there is no need to create different releases for different OS's.
Java also offers built in security, making the coding of the safe programs easier.
Java is fast, with clean code java is benchmarking in the same range as C++.
C# is the language that gets compared to java the most often. C# isn't as portable as java, and has very few features that java doesn't. This makes java much more attractive unless the program will ONLY be run on a single OS, in that case i might code it in C++.
I switched from years of C++ to Java because I was working on higher level stuff and needed the benefits of memory management, reflection, and sandboxed execution that I get with Java.
I have tried COM in the late nineties and could not touch it.
.NET looks promising and in many ways is now much better than Java. Unfortunately, being window-centric is a complete dealbreaker for me.
Another benefit is the awesome static analysis tools available e.g. FindBugs. These perform a lot of checking on your code above and beyond those performed by the compiler, and can help identify bugs and/or code smells before testing begins.
Lots of great reasons have already been mentioned. I'd like to add the political part. I trust Suns language a lot more than Microsoft alternatives. It's not because I hate Microsoft, it's just that Sun is going a direction with Java that I really like, and Microsoft is going a direction with .net etc. that I really don't like.
This is very subjective, I know. But to me it seems like Sun really want to create a great language, and try to make money somehow. While Microsoft seems more interested in making money by vendor lock-in and systems that looks great and feels great, but may not be as good as it looks in the long run.
So the way Microsoft is handling it right now, I don't even care about how good or bad it is, technically. I don't care, I'm not going to use it.
Java has everything I want from this kind of programming language, including all the boring political stuff most people just skip. I don't know about any other current language that has all that.
The main reason I use Java for most of my desktop app projects is for cross-platform compatibility. It's quite easy to make your app run on OS X, Windows, and Linux and look native on all platforms.
I use Java for our BPM platform and used Java in the past for enterprise web apps.
It depends on what you want to do. Considering language features, libraries available and IDE experience, I personally would choose C# over Java. C# 3.0 has many useful features that Java lacks, such as LINQ, Lambda expressions, etc. Some people prefer the huge library choice that is available for Java, but I think there are just too many ways of doing things. Java IDEs like Eclipse and NetBeans are getting better, but I think Visual Studio is still much easier to work with.
Of course,if you are not using Windows, you don't have much of a choice but to choose Java. Ruby and Python can be good options for things like utility apps and GUIs, including Web apps, but for enterprise apps that don't use Windows, Java is pretty much the only option.
Please don't follow blindly all java-entousiasts. Java has its own flaws. Java is great for rapid development, enterprise oriented stuff, and "high productivity" project (with the tons of projects, community,...).
And if one guy show me a benchmark highlighting how java code can be as optimal as C stuff doesn't mean the complete java solution is fast and lightweight.
Java will never find its way on some performance critical applications, like games, codecs, web browser. No major game software is developed in java, and not because the developper are not capable of writing one piece of Java code that has the same speed as C or C++, this is because the very limitations of the language involves that performance and memory consuption will never reach a good C/C++ code. Takes VisualStudio and Eclipse. Java is great for one stuff (productivity stuff, enterprise middleware), but if you want to write codecs, games, performance critical libraries, you'd better try knowing C.
But, one the other hand, you'll write the java code faster and safer, with C and C++ you're taking more risk (pointers!) and this takes usually more time.
And don't forget the joke "Write once, Debug everywhere", this is actually true. You have to deal with different JVM implementation nightmare with Java.
Other programming language have their interest, bash/python scripts for local scripts (repetitive action, fast and quick UI,...). Php or ruby for webapplication are very well deployed and documented on the web.
Using it for desktop applications.
Excellent IDEs available, wonderful API, "C-style" syntax makes it easy to pickup. Once the JVM starts, the performance is great.
Why would I choose Java - is it the most popular language out there right now? If not, it's gotta be damn close, so if I'm building a product I might choose this because it would be the easiest to hire developers for.
Why did I choose Java - because it's what I know best.
Why would I choose Java? If I happened to have a team of replaceable code monkeys developers that knew Java better than anything else, that is probably what I'd go with.
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.