Qt Jambi vs SWT for cross-platform GUI development - java

I'm currently involved in a project developing applications primarily for Linux (Fedora 10). However, it might be the case later on that we will have to port these applications to Mac OS X and Windows and we don't want to be caught out by choosing the wrong GUI toolkit.*
For a variety of legacy reasons we are locked into using Java. We are in the process of deciding between using Qt Jambi and SWT for the GUI. I haven't much experience in using either of them so I'm doing some small prototypes to try and get a feel for them. So far (just developing on Linux) there isn't much difference between them. However, there's a limit to the depth I can go in a short time. This is why I'm asking for help.
The particular features of interest to us are:
Frameless windows
custom shaped windows (i.e. not rectangular)
aesthetically pleasing
Does anyone have any experiences and/or insights into these two libraries that might trip us up later?
Agile programming people will no doubt jump on the phrase "might be ... later on" and say we shouldn't worry about it. However, in the absence of other deciding factors between the toolkits, future extensibility options will do. I promise not to write any cross-platform specific code until I have to :)
Update 11 Feb: Thanks for the great answers. For those that are curious, we will probably go with Jambi. It was mostly the style sheet functionality that won me over as they make easy a lot of the custom widget shape stuff we need to do. The Qt suite of examples showed that frameless, custom-shaped windows do indeed work on different platforms, so we shouldn't be caught short down the track. The LGPL release was why we were considering Jambi at all :)

I agree with Vinegar: Don't rule out Swing. I've developed both with Swing and with SWT, but not with Qt. With Swing, your code will be automatically cross-platform. With SWT, your code is cross-platform with a little effort, although not that much effort. Are you going to implement a local application, an Applet, or a Web Start application?
The advantage of SWT is that it uses all native widgets. (familiar Look-and-feel.) The disadvantage of SWT is that it uses all native widgets. (not as many widgets as Swing has) Whether this is more an advantage or a disadvantage depends on what you are doing and what your goals are. This means that Swing has a greater breadth of widgets. However, there are a few things that SWT does that Swing doesn't do as well (or at all) -- such as launch the system's native browser and execute JavaScript scripts in this browser.
If you consider SWT, consider it carefully. If you have certain needs (such as executing JavaScript in a browser window that was launched by your application), then it may be your best choice. However, if Swing can entirely meet your needs, it may be a better choice.
Hopefully someone else can provide information about Qt Jambi.
Note that support should be a consideration in your decision. With SWT, there is a smaller community supporting it. With Swing, a larger community, but this does not mean that fixes will get more quickly into a development release. With Qt Jambi and with SWT, if a bug is fixed, you just distribute updated libraries with your application. With Swing, you have to wait for an updated JRE. Neither is necessarily a dealbreaker, but it has to be considered.
Licensing fees may or may not be a consideration. SWT and Swing, of course, do not have licensing fees Jambi I don't know about either way, but it may depend on your intended use -- for example, are you distributing a GPL application, or a commercially licensed one.
Good luck.

I have no experience with SWT, yet I was working with Jambi/Qt, Swing and GTK as well. The only problem with Qt/Jambi is licensing in my opinion (you must either publish your soft under GPL or buy commercial license). You can't start writing software for free and then "see what happens". You must be sure that your software will be success, because you have to buy licenses. This in many times is not a case.
Regards.
Ooops, I overlook those comments, thanks for the reply. This is great news! Good move from Nokia.
#cursa that wasn't said, so also note that Qt/Jambi is more than widget toolkit. You have classes for networking, strings manipulation (along with regexp engine), mutexes, 2d vector & raster graphics, openGL and many more. This gives real boost to application development.
I also recommend downloading Qt package to Jambi noobies, because of very nice help browser called Assistant which Jambi is lacking. All the API of Qt and Jambi is the same (except slots and signals), even documentation is unchanged so you can use it interchangeably.

You know Qt Jambi is discontinued following the 4.5 release this month? That doesn't make it a bad choice. Qt has other community-maintained language bindings that live outside Trolltech's control.
http://www.qtsoftware.com/about/news/preview-of-final-qt-jambi-release-available

I wouldn't rule out SWT as it is a great success in the eclipse world. I've been using it happily for about 6 years and never had to resort to swing.

I would not recommend SWT. SWT is a bad designed library with a lot of hacks and bugs. You will be looking the whole time for workaround for the simple UI-tasks

Related

Swing vs JavaFx for desktop applications [closed]

Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I have a very big program that is currently using SWT. The program can be run on both Windows, Mac and Linux, and it is a big desktop application with many elements.
Now SWT being somewhat old I would like to switch to either Swing or JavaFX. And I would like to hear your thoughts on three things.
My main concern is what will be better for a desktop GUI application? (I looked online and a lot of people suggest that JavaFX is just as good as Swing, but I didn't see many valid arguments except simple opinion flame wars). It has to work on both Windows, Mac and some popular Linux distributions.
What will be cleaner and easier to maintain?
and what will be faster to build from scratch?
I am using MVC methology in my application, if that is of any help.
What will be cleaner and easier to maintain?
All things being equal, probably JavaFX - the API is much more consistent across components. However, this depends much more on how the code is written rather than what library is used to write it.
And what will be faster to build from scratch?
Highly dependent on what you're building. Swing has more components around for it (3rd party as well as built in) and not all of them have made their way to the newer JavaFX platform yet, so there may be a certain amount of re-inventing the wheel if you need something a bit custom. On the other hand, if you want to do transitions / animations / video stuff then this is orders of magnitude easier in FX.
One other thing to bear in mind is (perhaps) look and feel. If you absolutely must have the default system look and feel, then JavaFX (at present) can't provide this. Not a big must have for me (I prefer the default FX look anyway) but I'm aware some policies mandate a restriction to system styles.
Personally, I see JavaFX as the "up and coming" UI library that's not quite there yet (but more than usable), and Swing as the borderline-legacy UI library that's fully featured and supported for the moment, but probably won't be so much in the years to come (and therefore chances are FX will overtake it at some point.)
As stated by Oracle, JavaFX is the next step in their Java based rich client strategy.
Accordingly, this is what I recommend for your situation:
What would be easier and cleaner to maintain
JavaFX has introduced several improvements over Swing, such as, possibility to markup UIs with FXML, and theming with CSS. It has great potential to write a modular, clean & maintainable code.
What would be faster to build from scratch
This is highly dependent on your skills and the tools you use.
For swing, various IDEs offer tools for rapid development. The best I personally found is the GUI builder in NetBeans.
JavaFX has support from various IDEs as well, though not as mature as the support Swing has at the moment. However, its support for markup in FXML & CSS make GUI development on JavaFX intuitive.
MVC Pattern Support
JavaFX is very friendly with MVC pattern, and you can cleanly separate your work as: presentation (FXML, CSS), models(Java, domain objects) and logic(Java).
IMHO, the MVC support in Swing isn't very appealing. The flow you'll see across various components lacks consistency.
For more info, please take a look these FAQ post by Oracle regarding JavaFX here.
JavaFX Frequently Asked Questions
No one has mentioned it, but JavaFX does not compile or run on certain architectures deemed "servers" by Oracle (e.g. Solaris), because of the missing "jfxrt.jar" support. Stick with SWT, until further notice.
I don't think there's any one right answer to this question, but my advice would be to stick with SWT unless you are encountering severe limitations that require such a massive overhaul.
Also, SWT is actually newer and more actively maintained than Swing. (It was originally developed as a replacement for Swing using native components).
On older notebooks with integrated video Swing app starts and works much faster than JavaFX app. As for development, I'd recommend switch to Scala - comparable Scala Swing app contains 2..3 times less code than Java.
As for Swing vs SWT: Netbeans GUI considerably faster than Eclipse...
I'd look around to find some (3rd party?) components that do what you want. I've had to create custom Swing components for an agenda view where you can book multiple resources, as well as an Excel-like grid that works well with keyboard navigation and so on. I had a terrible time getting them to work nicely because I needed to delve into many of Swing's many intricacies whenever I came upon a problem. Mouse and focus behaviour and a lot of other things can be very difficult to get right, especially for a casual Swing user. I would hope that JavaFX is a bit more future-orientated and smooth out of the box.

Java Swing : Write cross platform application (basically CRUD)

I need to write cross platform application (basically CRUD).
Is usage of Java Swing good idea? Or is it out-dated and you know better solution?
I dont want to use like 5 languages for various stuff, one or two should be enough.
Java and Swing will absolutely fit the requirement, and you will be able to make do with just the language runtime as downloaded from Oracle/Sun and nothing else. Java is one of few languages that comes with a complete and powerful GUI library of its own already included.
If I were to write a program like this these days, that's what I'd use.
Swing is complete, maintained, well documented, and implemented in Java, ensuring cross-platform portability. Most relevantly, it's part of the Java language so no other downloads for the user to manage / bloat your program.
Although the default look and feel is ugly, Java 7 is to update the default look and feel of Swing to Nimbus, which looks very glossy.
If your question relates to using the language itself, I'd say "yes". Java is, like Swing, well documented and highly developed. It may seem verbose but if there's a problem, you can sure tackle it in Java.
Personally, I've always much preferred the Standard Widget Toolkit in terms of GUI toolkits myself.
Some argument and discussion.
Java/Swing will definitely do what you want. There are other solutions such as .NET/Mono, Various cross platform GUI libraries and C++.
If I had to decide today which to use it would be Java/Swing. Java because it is better supported, Swing because it's built in and JDBC simply tips the balance away from the others.
Gavin's right +1 for the SWT. If I didn't already know Swing I'd consider SWT before making a final decision. However I do know that Swing does the job well.
Since both good java answers are already given, It should be possible to do the UI in c# as well (as long as you don't use anything Windows specific). System.Windows.Forms type applications can run on Windows, linux and Mac OS X (with mono). It does require a bit more work to get the packaging done for each platform you want to support, but it is possible.
(If you already know java you're still better off using that though as the support is better across platforms and it doesn't require your users to install mono or .net)
Java/Swing is fine. I would recommend getting a license for JFormsDesigner or one of the other UI layout tools that makes life much easier.
Also, check out SwingX which is people who work at Swing making custom controls and what not that look good and are very useful.
That's also a good place to look for best practices.
Maybe you can decouple the front end from the back by creating XML request/response streams and using web services. Then you can write the front end in whatever technology you want, as long as it uses an appropriate web client.

Where are Swing applications used?

Are Swing applications really used nowadays? I don't find a place where they are used. Is it okay to skip the AWT and Swing package (I learned a bit of the basics though)?
If you are writing for the web exclusively, you can probably skip Swing, but otherwise you're absolutely going to run into it. I've never worked on a non-trivial Java app without a Swing GUI.
Also, Swing is one of the better APIs to use. If you use most others, you are going to find them more difficult to use and/or platform incompatible. (If anyone reading this is aware of exceptions to this, please leave comments, I haven't looked for a while and am kind of curious if anything better has become available)
Other JVM languages like JRuby and Jython are often used because of their access to Swing.
You may checkout Swing Sightings.
This website is hosted by SUN and it is dedicated to sw projects that use Swing.
There are a lot of projects using Swing ...
http://java.sun.com/products/jfc/tsc/sightings/
Swing is heavily used in business specific (vertical)/internal application development.
Hmmmm... how about NetBeans? You know, the IDE? It uses Swing.
Swing applications are used in most cases where a Java app runs on the desktop. Sometimes you don't even know - for example, LimeWire is a Java Swing application.
When learning Swing, you'll find that you will come to know those parts of AWT that are still important, such as Event, LayoutManager, Graphics, Font, Color, etc.
You should certainly write Swing for desktop Java, only using AWT to the degree that Swing demands it.
I'm sure people can come up with examples of very good Swing apps besides SQL Squirrel and IntelliJ.
I think that RIA technologies like Flex, Silverlight, etc. are ascendant because the web and services are taking mindshare from desktops. It's not just Swing that's losing out.
Whenever you want to write a desktop GUI app for non-Windows OS, you use Swing as the only sane and guaranteed cross-platform GUI framework.
Besides, Swing has a very good design. I recommend to learn it anyways, to make yourself a better programmer.
Check out Filthy Rich Clients. It explains some of the history of AWT and Swing. Swing, being a lightweight alternative (successor) to most of the AWT classes.
IIRC jEdit is also a Swing app. Quite a popular text editor.
Skip AWT and Swing? To jump where? SWT? Web-based development?
In the broader sense, I have a number of Java applications, although I am not too sure if they use Swing or SWT.
Lot of database tools like SQuirreL SQL Client are written in Java. I think SQuirrel uses stuff from Netbean, which is, of course, Swing based.
yEd is written in Java, probably Swing.
A number of P2P softwares are written in Java, including Frostwire (I see no trace of SWT there, but I can just miss it).
And this list is far from exhaustive!
Lol! I forgot to mention the software suite made by the company I work for! It is quite specialized, used by mobile phone companies to monitor health of their network nodes (superficially looks like a spreadsheet). Totally Swing based.
While Swing has some cross-platform look-and-feel deficiencies and it would be nice if it was updated to support generics, it is still well designed and quite usable. I have always been a fan of the sheer amount of customization offered. SWT is nice and is more native, but you give up some power and control with that as well. In addition, it seems simpler to use, which can be a plus, since Swing can be overly complex due to its flexibility.
Geertjan Wielenga often blogs about applications based on the NetBeans platform, and therefore Swing. The applications range across the board from rather small esoteric applications to very large, mission-critical systems (Boeing Aircraft comes to mind). Many of the enterprise-level applications that Geertjan misses are mentioned on Planet NetBeans. It seems like every few weeks there is an announcement or description of such a program.
As noted above, lots of tools use Swing including the IntelliJ IDEA IDE, a favorite. I'm surprised no one else mentioned it.
Sun also used to maintain a Swing Sightings web site, but it hasn't been updated in a few years.
Where I work, Swing is used in the presentation layer for a very large document management system. In my own development experience I've used Swing for desktop applications in the areas of image processing, device control (video, motors, etc.), math, statistics, and medical devices.
BTW, I agree about the slowness of file choosers. But there are lots of alternatives that will use the native file chooser. It can just be a bit jarring if the L&F's don't match up very well.
EDIT: Oh, and as others have mentioned, it's very easy to use Swing from other languages on the JVM. With Clojure, for example, it is even easier to use than in Java, in my opinion.
There is no universal question to whether it is ok to skip something or not. It's a matter of priorities. While Swing has a lot to teach you (and it is too heavily infused with AWT), if you're never going to be writing GUIs you may be better off investing in something else.
Swing, while ugly as hell, is still used in many places. A quick search on "java swing" in Indeed or dice would reveal many jobs and industries that require it.
Are you skipping it for an exam/interview? Besides really good apps like IntelliJ IDEA and NetBeans, there are lots of Swing like frameworks [SWT (Eclipse), GWT etc.] which you can learn faster with Swing knowledge...
You should probably be looking at JavaFX for future work. As the FAQ states,
Sun is not replacing Swing with JavaFX Script. Instead, JavaFX Script makes Swing easier to use.
Using/learning it will give you a very good understanding of the important Swing concepts, and how they fit in with "the future". I haven't used JavaFX yet, but heard very good things about it.
Armitage tool is made in swing , GUI tool of metasploit framework.

JavaFX is now out: Are Applets and Java Desktop officially dead/dying? [closed]

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.

Why would you choose the Java programming language over others? [closed]

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.

Categories