Skip to main content

What's holding back Java on the desktop?

Appearance issues
15% (134 votes)
Performance issues
25% (220 votes)
Deployment issues
29% (259 votes)
Difference in EE / SE programming styles
3% (26 votes)
Poor multimedia support
8% (75 votes)
Legacy perceptions
15% (131 votes)
Other (please comment)
5% (44 votes)
Total votes: 889

Comments

Top Desktop Application

Register as new user in ThinkFree and try it for a while then think if it possible to wirte WEB IDE like netbean or eclipse.

Top Desktop Application

First, ThinkFree is an applet, not DHTML, JavaScript. Applet are about halfway between a Desktop app and a webapp. They require the internet connection and run in a web browser, but they have the Swing UI toolkit and the slightly restricted ability run all kinds of client side code. Second, I never said it wasn't possible, but that doesn't mean it will yield a good user experience. Finally, why would I want to force something like Netbeans or Eclipse to run in a web browser? What about users on slow connections? What about users who, for security reasons, limit or disable JavaScript? What is the advantage of running things in web browsers? Great, wonderful, you can do it, but does it make sense? A user doesn't care that it runs in a web browser, that it's written in Java or C++ or Fortran for that matter. A user only cares that it is easy to use and functional. I'm beginning to believe that the 'Everything must be a webapp' mentality is a mental sickness. ;)

Top Desktop Application

First, I Know that ThinkFree is an applet and if you forgat that java in 90s start as an applet. So, webapp mentality give birth to java and if you look at smalltalk it remain at desktop and it almost dead. Second, bugzilla, wiki and JIRA are webapp, why not include the IDE also. Finally, there are framework and JSF library that support AJAX for easy development.

Ugly API

It's very confusing that there are both java.awt.Button, java.swing.JButton in java desktop api. And lots of examples shows that the APIs are VERY UGLY...always painful to write swing code. God, why should a Button be JButton!!!

Psychology

I suppose the fairly lesser quantity of applications used by mass users needed to be crossplatform. Ordinary user obtains the habit to uniformity in general as times goes by, computer software isn't an exception. A Java application sticks out of the line. If application starts differently, it sticks out... If application's UI has pauses in respone, it sticks out... The Java API is the best, but it doesn't matter for ordinary users who perceive the software with organs of sense.

Formatting formatting formatting

Deployment deployment deployment. The language is great, the API's are great, but trying to show anyone your work can be difficult. Lets not even talk about windows for a second, on all platforms, would it be possible for Java manage itself? Let me explain more: * Having multiple installed JVMs is a fact of life. Can the JVMs work together to decide which one should be handling a particular application? o JVM-A happens to be the one in the path - it gets a request to start a program, it checks the program for the "minimum version" necessary to run. If it decides it can't handle the application then it passes it off to JVM-B. This would mean that all the other JVMs would have to know about each other and you would have to keep some meta-data at theapplication level like "minimum version" and "preferred version" etc. * Can we have a centralized management system for Jars that spans all the installed JVMs? o I am envisioning a system like the many of the Linux package managers. I could install a jdbc driver once, then any other application that needs it can use it. You would probably need to keep track of jar versioning. The the install for an application could just be a list of the necessary jars and where to get them if they don't already exist. This would cut down on the amount of data you need to download. * Can we have a system that programatically allows us to ask the JVM to run a program? o What I mean is something besides a command line. On all platforms you have to muck with a very long command line. For our program it's at least 1024 characters long. Could there be "java launcher" program that you could rename "myapplication.exe" and just use configuration files to tell the app how to be launched? I've written a few things like this in NSIS, but they amount to the a complied version of the steps you would use in a .bat file. It's possible that all these tasks could be integrated into a systems separate from the JVM. A sort of JVM management system. It could even be platform dependent and take care of whatever is necessary to integrate whit that particular platform, menus, icons, dock, taskbar etc. thanks for reading, Collin

JVM management

WebStart already manages multiple JVM's and will respect requests in a JNLP file for a particular JVM or one with a version that satisfies a pattern. So perhaps all we need is a modified version of this for use with locally installed applications.

Formatting formatting formatting

Overall nice thought, but, to play devil's advocate for a minute, how are you proposing to manage different versions of proposed JVM management system? :)

It's been said before and applies here too…

There can be only one... the newest one. Unlike multiple JVMs there can only be one magement system. The managment system would have to be replaced every time a new install happens. That’s not too unreasonable I think.

Deployment deployment deployment.

Deployment deployment deployment. The language is great, the API's are great, but trying to show anyone your work can be difficult. Lets not even talk about windows for a second, on all platforms, would it be possible for Java manage itself?

Let me explain more:
  • Having multiple installed JVMs is a fact of life. Can the JVMs work together to decide which one should be handling a particular application?
    • JVM-A happens to be the one in the path - it gets a request to start a program, it checks the program for the "minimum version" necessary to run. If it decides it can't handle the application then it passes it off to JVM-B. This would mean that all the other JVMs would have to know about each other and you would have to keep some meta-data at theapplication level like "minimum version" and "preferred version" etc.
  • Can we have a centralized management system for Jars that spans all the installed JVMs?
    • I am envisioning a system like the many of the Linux package managers. I could install a jdbc driver once, then any other application that needs it can use it. You would probably need to keep track of jar versioning. The the install for an application could just be a list of the necessary jars and where to get them if they don't already exist. This would cut down on the amount of data you need to download.
  • Can we have a system that programatically allows us to ask the JVM to run a program?
    • What I mean is something besides a command line. On all platforms you have to muck with a very long command line. For our program it's at least 1024 characters long. Could there be "java launcher" program that you could rename "myapplication.exe" and just use configuration files to tell the app how to be launched? I've written a few things like this in NSIS, but they amount to the a complied version of the steps you would use in a .bat file.

It's possible that all these tasks could be integrated into a systems separate from the JVM. A sort of JVM management system. It could even be platform dependent and take care of whatever is necessary to integrate whit that particular platform, menus, icons, dock, taskbar etc.

Thanks for reading,
Aberrant

What's holding Swing back.

People I've talks to think it's too complex and too slow. I think this means most people have done a lot more web UI work (servlets, JSP, etc.) than Swing development. For myself, I started doing UIs in AWT back in 1997 and I've never really done anything but AWT/Swing development. Personally, I like Swing.

Application packaging, JVM management

- Look what Apple has done with the central JVM version management. The JVM should be updateable with a software update. If one JVM is installed on a users computer it should itself try to keep updated. - If a JVM is already installed and the user tries to install an additional one, the installer should default to simply update the existing JVM. Many bad experience comes from age-old JVMs still installed or because a user has dozens of JVMs installed. - Distribute JVMs preinstalled and via CD-ROMs of Computer magazines. A major German computer magazine recently distributed the actual .net framework and the express version of Visual Studio. The same can be done with Jave+Netbeans. Make Java CD-ROMs as common as those AOL ones. If the user installs an old version, the JVM installs from the CD and then explains, that there is a newer version and tries to update itself (only a delta update !). Many user cannot or do not want to do major downloads. During installation show some techno blah blah... that the modern JVM technology increases security; make better uses of multiple cores and so on. Most people simply reiterate the first thing they heard about something, but do not understand anything. - Deployment of java applications must look exactly like native applications on windows. .exe files are needed for the average user ! No average user wants to double click .jar or .jnlp files in times when one must not double click unknown files. Include a packaging tool in the JDK. Java will be suddenly accepted on the desktop, if its usage cannot be recognized by the average user.

Hmm.. how to select more than one?

Management

"This new application, let's write it as a webapp with EJBs" "But we don't even have any requirements yet" Ajax seems to be the answer to everything at the moment. But any half-decently written Swing or SWT client-side app will be way more usable than the best Webapp.

Answer: Sun

1) IBM offered Sun a cooperation, but Sun denied. 2) The (IMHO ugly) metal look and feel vs the mostly preferred native look and feel (keyword: usability) 3) Missing support for standards: no support for native widgets, missing standard components like font chooser, directory chooser, calendar component, link component, no look and feel support for color chooser (only the metal color chooser is implemented), no browser integration (into a swing app) ... today you can call them standard components 4) Missing desktop integration: no integration in app menu, no desktop icon, missing standard for setup/uninstall. 5) distribution size, missing native execution (java -jar something or running a batch script is not very intuitive - and outdated)

Answer: Sun

Am I reading an avid supporter of IBM and SWT behind this post? Sorry, could not resist, it's so blatantly obvious... And what makes you feel IBM would do any better? Anyway, you might have named the culprit, but you have no solution.

Difficulties in development are probably more important than dep

I agree that deployment issues are an important set of factors hindering the use of Java for desktop apps but based on my experience at a few locations, the high costs of developing robust, commercial Java desktop apps is what causes many such projects to fail. Fortunately, the recent availability of the Matisse GUI Builder in Netbeans does help to reduce such costs to a level where Java is now competitive with Microsoft tools. This is based on my recent delivery of a new GUI for an existing application using Netbeans in much less time than I expected. Designing the GUI class package as being indepedent from the rest of the application did help in streamlining the completion of the code. Good object/package/component design is still important for reducing development costs.

Of course, legacy perceptions

Even this thread is full of them:
  • 40MB JRE download (no comment on size, plus huge fraction of users already have Java installed)
  • users being confused about either JNLP or JAR file types (who cares what the file type is as long as it launches an app)
  • the need to patch JRE to get a "non-trivial app" working
  • To top that off, most people are simply unaware of what new APIs Java platform supports. For example, try asking about fast 3D in Java, and awareness of existence of JOGL and its performance would likely be missing from the argument of the countering side.

Of course, legacy perceptions

Just wanted to point out that the JRE is 7.1 meg (or thereabouts) download size. Pack200 is used to compress the size of the jre down.

Of course, legacy perceptions

users being confused about either JNLP or JAR file types (who cares what the file type is as long as it launches an app) Nearly all users I know do not know that where the .exe file is, if they see a .jar file, with the default icon. This is a major point !

Of course, legacy perceptions

Nearly all users I know do not know that where the .exe file is, if they see a .jar file, with the default icon. This is a major point ! Please! Please, would you be reasonable? Are you saying your users not know how to launch an application by double-clicking on a document that is associated with it? Do they also insist on having the actual EXE of Internet Explorer, or Firefox, or whatever it is they run on their desktop instead of a shortcut to it? Ridiculous...

History...

It's not performance apearance or anything like that. It's history. Upper managemnt had experience of java apps a few years ago. they where generally clunky, slow, needed a pretty good machine (memory & CPU) Because of this, they now have the perception that java is as java was. That a modern java app would still be slow, clunky/ugly. (included with the fact that they previously where - they also from time to time come across a new java programme that is all of those because the developer just didn't get it when it came to writing swing code.)

History...

At my company we are slowly getting past this perception. There are several tools we need to build that would be far easier/faster to build in Swing. But past edict set forth that 'there will be no Java outside the webapps'. Of course our companies first experience was with Swing several years ago, and the developer didn't know what he was doing, so the experience was truly frightening.

Databinding is the key

Personally, I believe that having no easy, standard databinding API is what is hindering Java on the desktop the most. Many companies still have VB programmers to build quick and easy database driven business applications. It is a lot harder to do in Java, so many use another tool.

Databinding is the key

I agree that data entry (aka forms) is the key, beside databinding a standard validation framework would be of great value.

Databinding is the key

JGoodies makes an excellent Binding framework and Validation framework.

so close!

It's like Desktop Java ran this incredible marathon... and then suddenly gave up, just yards from the finish line! Users don't understand what .JNLP or .JAR files are. We need a way to package apps into something analagous to a .WAR file (.DAR?) that can be trivially wrapped into a native executable (.EXE, .app, etc.) via a tool in the SDK bin directory. I have experimented with many, many packagers. The best I have seen are one-jar and NSIS/Jelude. one-jar is really cool, but unfortunately JCE implementations won't trust its custom class loader. Looks matter, too. Web Start needs to support PNG and transparency for application icons so that Java doesn't stick out like a sore thumb on the Dock. Please take heart, Sun! You have done and are doing (Matisse!) are wonderful job. Don't be afraid to get a letter dirty with platform integration. The rivers can still flow thru the deskop mountains with delicious, piping-hot Java!

Maybe it's better now but...

... I remember seeing some of the classes that Borland had to write to get JBuilder to work. Some existed to work around bugs or non-performant pieces of swing. These would all break between jdk releases, so each JBuilder had to be tied to specific release of swing. So unless you distribute a jdk with your app, how can you make sure it will work for the client once it hits their machine? So if you want to have 3 different (non-trivial) java apps on your machine you're going to need a separate runtime for each of them. Part of the issue is with Swing too. It's a great low level toolkit, but it is not a good gui application framework. Media support is bad in Java compared to what? C or C++ where there is no support in the language at all?

Top Desktop Application

The Polls should be, What is the Top Desktop Application Usage?
1. Internet Browser (IE, Firefox and Opera) I can't imagine anyone don't use it. 94%
2. Media Player (iTunes, Windows Media Player and RealPlayer) 1%
3. Communication Program (Outlook, RSS, Chat, VoIP Skype) 1%
4. Sharing Program (Emule and Kazaa) 1%
5. Office Suite (OpenOffice, MS office and Adobe Reader) 1%
6. 3D Game Application 1%
7. Development and Design (AutoCAD, Macromedia Flash and IDE netbeans) 1%
So, JAVA on the Desktop? it doesn't matter !!!

Top Desktop Application

I'm not really sure how you came up with your ranking. Apperently everybody spends nearly all their time on the computer surfing the internet, but whatever. Ignoring the percent rankings you gave to your categories here's my $.02. 1. I really don't think any new commer to the browser market has much of a chance without radical improvements. Such radical improvements are very hard in the browser market because sites have to be written to take advantage of those improvements. Kind of a chicken and egg scenario. However Opera Mini is a very popular browser for cell phones written in Java. It's a bit of a streatch to call it a desktop app, but whatever. 2. See my previous comment about the sad lack of quality multimedia support in Java. 3. Here you list a program, a technologies, a type of app, and a company, huh? Well I'll just talk about communication software. There are some pretty solid RSS readers written in Java. Communication software in Java is a snap to write. The problem is the lack of interoperability between the old, established, programs. New programs have a very hard time building a user base. What we really need here to see some great inovation is the adoption of open standards. I think that this is one area Java could explode into given the right market conditions. 4. I guess you've never heard of the Azureus BitTorrent Client. currently the number 3 most downloaded app from sourceforge. Just happens to be written in Java. Also the 2006 winner of the 'Community Choice Awards' as 'Best Overall'. 5. There are good office apps written in Java, but again the problem is lack of open standards. Hopefully popularity of OpenOffice (not written in Java), and understanding of what vender lockin from proprietary file formats costs. 6. Java is just comming of age in the area of games and graphics. There are some retail, on the shelf, 3D games written in Java, and some great thing in the pipe in terms of improved language support. 7. Netbeans, Eclipse. Other than that getting a real professional to switch programs requires more than a better program. It has to be so darn good as to make up for all the time they have invested in their old app of choice. (This is one of the major problems of Linux adoption. You can't just tell a professional using Photoshop to switch to Gimp). In short Java is on the desktop and growing. I don't think the fact that a program is written in Java should be some great feature by itself. Programs should be written to be useful, and 'oh, by the way, it's written in Java' as an afterthought.

Top Desktop Application

You miss my point, try not use browser for one week and than try with other application for one month. The demand on Desktop Application less than web Application. So, java running on web browser has better chance on Desktop. If you don't believe me, go www.monster.com and count number of job for JAVA Web Developer.

Top Desktop Application

It wouldn't take much for me to not use a web browser for a week. I'd get behind on the news, probably have to catch up on a few podcasts. Pay more attention to my bank receipts. But I could do it. Really what do you have to do online in a web browser? If I tried to stop using Eclipse, Lotus Notes (man I hate notes), or Magic Draw for one day I'd be fired. Well, I might be able to get by without Magic Draw for a couple of days. I don't doubt that there is significant demand for Java Web Developers. Just because Java Web Developers are in demand doesn't mean Java on the Desktop is a moot point. We can do both. Web apps are by nature limited. Some things work well in web apps, more complicated things do not.

How big is your JRE?

I don't know where you guys are all getting this FUD about the JRE being 40-50MB in size. Hop your whiny little but over to java.com and see that the offline install is 16.0MB. My biggest problem with large desktop apps is that I haven't taken the time to learn one of the large number of third party install packages most of which can verify the installation of or prompt the user to download the 16MB JRE. For small apps I love JWS, puts an icon on the desktop (if the user wants it), in windows the app is put into the add/remove programs list. The only problem is the user has to have the JRE first. The biggest hangup I see for Java on the desktop is bad perceptions (often from Java developers). The media support is another huge problem, but most business apps (which is what I deal with) don't need any fancy multimedia capabilities.

won't matter much anyway

Today: Desktop ~= Windows. When Microsoft bundles a C# runtime with Vista, the game will be over in the desktop deployment area for managed runtimes. See IE vs Netscape. WMP vs. Real. The managed runtime competition for the Linux desktop is pretty much decided in favour of C#, with Mono being bundled with all major distributions. So, beside the Solaris desktop, what desktop could Java possibly 'own' in the future? Looking Glass? ;) cheers, dalibor topic

won't matter much anyway

Actually I wonder why Sun don't want to shut down whole windowz desktop in one week. The only thing they need to do is to permit to Excelsior Jet to distribute a part of jre. By now you CAN compile you WHOLE java 5 desktop application to an exe. With version of Jet 4.5 there will be 2 files - one is a compiled exe and another is the "rest" of java API packed as jar. The application don't need this file, but you can't rid of it because of the license... What could be easy to deploy than one exe file. No dll needed, no fancy dependency on OCXxxx o MFCxyz... You can compile for linux if you wish too... By now I'm happily distribute small tools done in java+swt and don't care about odbc/mfc/what else dependences... Cheers.

Deployment

The main problem is how to deploy.... You could buy a 3rd party installer like install sheild.. but hey this is a java app and wouldnt it be great to have a 100% pure java installer... Next comes the other little problems. There is no way to create a windows / linux desktop icon. There is no way to insure that the user has a proper vm.. so if you include one that ups your foot print by 50 megs! java needs to take the best features of applets , JWS, and swing apps and get its act together to get the desktop front moving. add the smarts of java webstart features to the average java app. (ie detect what libs are needed and installl only them automatically, be able to create desktop items....)

All of the top three points

I guess it's appearance, performance and deployment together, performance being the least problem as many desktop computers and laptops now feature enough RAM to deal with complex Java applications. But appearance is a real bummer: Most applications I program are used by Windoze users, and Swing's Windows Look and Feel is, while being close to the L&F of native windows applications, not right on spot. And it's these minor differences that tend to annoy powerusers completely, so that we have to work around them -- probably losing platform independence along the way. More serious, though, are the deployment problems mentioned by other commentators. I know that you cannot have platform independence without a runtime of a given size, but the SE nowadays contains sooo many packages my Java applications never use. So it's no mystery why one of the enhancements most requested in the Java bug database is a smaller base JRE with optional packages that can be included on demand. SUN, please listen to your customers and break up the monolithic structure of the SE! We know it's hard (maybe nearly impossible), but at least try, for god's sake. I would even be willing to sacrifice backwards compatibility of the API for this... Thanks, Lars

Always Deployment

With the platform not supplying a JRE and now "forward compatible" JVM that will download the latest version when needed, there's really no guarantee, without installing your own JRE, that the application will run. Then, people complain that they are littered with JRE versions etc. It's a tough call. I think that the l&f is fine, most people aren't going to notice some minor diferences. Legacy perceptions aren't there for real users, they just want the application to work period.

Always Deployment

With the platform not supplying a JRE and now "forward compatible" JVM that will download the latest version when needed, there's really no guarantee, without installing your own JRE, that the application will run. Then, people complain that they are littered with JRE versions etc. It's a tough call. I think that the l&f is fine, most people aren't going to notice some minor diferences. Legacy perceptions aren't there for real users, they just want the application to work period.

Deployment

Users want to a small download even though broadband connections are getting more and more ubiquitous. Telling them to either downloading 12MB for an application with a bundled (stripped) JRE, or telling them to go to www.java.com and download the 40 (?) MB Sun JRE simply doesn't cut it. You lose.