Can the Java Plug-in compete?



Why hasn't Java become the dominant technology in RIA development?
I'm not the first person to ask this question, nor will I be the last. It is unbelievable to me that the company that invented the RIA over a decade ago has made little or no progress in this field and presents absolutely no challenge to inferior technologies that came later. JavaScript was named "Java" script deceptively to give it better visibility in the marketplace, but given its dominance in the RIA market, you'd never believe it.

I have been developing software for over 25 years now with the majority of my experience in C++ development and object-oriented analysis and design. Wanting to move into the web market, I started doing RIA development a few years ago. I was horrified by the development options available to me and the seemingly infinite amount of hoops I had to jump through to get even the simplest application functionality implemented and working correctly. I had been using Java to do backend work and had really come to like it. To me, the ideal situation would be to use Java to do the client-side work as well as the server-side work. Not only would I be using a real OO programming language, I'd also be using a single technology across the board. The problem was that there really was no nice client-side Java solution available. Swing was just too cumbersome and inflexible and other products had similar drawbacks. What I really wanted was a client-side solution that was as easy to use and just as flexible as HTML/CSS for building a UI, but provided the dynamic and robust programming features of Java. So I quit my full-time job about 18 months ago and started designing a Java-based RIA product called the Galileo RIA Framework (www.galileo-riaf.com).

One of the many frustrations that I had experienced working with JavaScript was the problem of inconsistent appearance and behavior on different browsers; therefore, when I started designing Galileo one of its primary requirements was that it be able to run on all major browsers on all major platforms and produce a consistent looking UI. Knowing the history of the Java Plug-in, I wasn't sure if it would meet this requirement. Much to my relief, it turned out that the latest Java plug-in (1.5 at the time) worked fine with all the latest and greatest browsers (IE, Firefox, Netscape, Opera, Safari, and Camino) on all of my test machines which included Windows XP and Vista, Mac OS-X, and a few Linux distros. This was great. I figured now all I had to do was focus on developing the actual UI framework and I would have the product I had been longing for and a product that the Java community would be excited about.

I recently released Galileo as a Beta and while many developers who have looked at the product have admitted that it is an impressive product and that they'd like it to gain much success, they are reluctant to use it because it depends on the Java Plug-in. This has been a major disappointment to say the least. I knew that applets had developed a stigma over the years, but I didn't realize how pronounced the distaste for the plug-in had become. The negativity and skepticism within the Java community itself is so overwhelming that any hope for wide acceptance of the plug-in seems impossible. The funny thing is that all the developers I have talked with would like the plug-in to become widely accepted, but in order for it to become widely accepted, it would have to be used, however, most website developers are hesitant to use it, because, well, it's not widely accepted.

I want to change this. Not only because the success of my product depends on it, but because I would like more job opportunities to be available to me as a Java programmer as the RIA market continues to grow.

Why did the Java Plug-in fail in the first place?
My guess is that there were several major reasons for the failure of the Java Plug-in. One, applets and the plug-in were introduced at a time when most users were limited to dial-up access to the internet. Downloading the plug-in and the applets that used it took too long for a normal user's patience. Two, a Swing UI compared to an HTML website designed by a graphics artist looked terrible. Three, platform and browser compatibility may have been an issue also, but not being involved in Java development back then, I don't know if that was an issue or not. Four, it has been said that installation of the Plug-in was not straightforward and could have been difficult for non-developers. Five, the web was still pretty new itself. The concept of the RIA didn't exist; therefore, there wasn't any pressure for websites to be anymore than straight HTML. Adding technology that complicated implementation, limited potential visitors, and looked bad, just didn't make any sense.


Can the Java Plug-in compete now?
I'm optimistic it can for several reasons. One, according to the latest statistics I've read, 86% of U.S. internet users now use broadband. Download times for JAR files and other resources have become negligible. Two, Sun has finally decided to rewrite the plug-in making it easier to detect, download, install, and upgrade. Also most major browsers will prompt the user in a standard way to install the plug-in if a page that requires it is loaded. Three, new operating systems / machines are coming with the Java plug-in already installed. I know both my Windows Vista machines from Dell did, my Mini-Mac from Apple did, and several distros of Linux install the plug-in when the OS is installed. Four, installing a plug-in just isn't a big deal for users anymore. According to a June 2008 survey 99% of internet enabled desktops have already installed the Flash plug-in and 85% have Java installed. Five, standard HTML websites are no longer the standard. To be competitive, websites will have to continue to evolve with RIAs being the latest evolutionary step. Where standard HTML sites with bits and pieces of JavaScript could be developed by graphic artists and other non-developer types, RIAs, because of the complicated implementations, require software developers. Where the major driving force in the web development market used to be graphics artists and non-developer types, as the RIA market grows software developers, many of which are Java developers, will become a greater driving force. This opens up more opportunities for Java. And six, with a framework like Galileo which allows easily customizable UI's that can look as good as any HTML/CSS based UI, aesthetics are no longer an issue for Java UI's.

I was discussing this issue with Marty Hall of www.coreservlets.com this week and here's what he had to say:

I would love it if a Java-based solution gained some traction in the RIA world. I spend a lot of time doing Ajax training, and right now, Ajax is tremendously complicated for developers. Developers have to learn xhtml, XML, JSON, JavaScript, Prototype, 37 other JavaScript libraries, and a server-side technology (servlets/JSP, PHP, ROR, or whatever). Even with integrated technologies like GWT or JSON-RPC, there are still an awfully lot of underlying technologies for a developer to master, and the interface is still limited by what current browsers can support."

I really hope your framework catches on. It would be a good thing. You could build apps that were so much better if you had a real programming language and a single underlying technology.

The more compelling apps out there that get people to install Java in their browsers the better. And the more powerful but simplified GUI frameworks like yours, the better.


JavaRiaDev.org
I believe a window of opportunity has opened to give the Java Plug-in a rare second chance. It appears that Sun believes this too, since they have taken the initiative to redesign the plug-in and to create JavaFx. However, with no disrespect to Sun, if Java developers expect the plug-in to succeed due to Sun's efforts alone, I think they are sadly mistaken. In order for the plug-in to succeed, a concerted effort by the Java community will be necessary. For this reason I have created JavaRiaDev.org. The main initiative of this effort will be to pool developer resources to create RIAs that utilize the Java plug-in and appeal to a broad audience by coming up with new ideas for websites, copying successful website ideas and making them better, and/or trying to forge strategic partnerships with existing websites that already have a substantial user base who are looking to upgrade to RIA technology. The second initiative will be to provide the appropriate resources to help other developers interested in Java RIA development. I, of course, will be pushing Galileo, but will welcome the use of any product that promotes the use of the Java plug-in.

There will no doubt be skeptics in the Java community who say this is a fool's errand. But for those like me who are not content sitting on the sidelines waiting for others to decide their fate, I say join me and help me in my effort to make Java, if not the dominating, at least a viable option for RIA development. Personally I'd like to have an impact that creates the general opinion that any machine connected to the internet that isn't equipped with the Java plug-in is an inconvenience to the user. If a machine has a modern browser there's no reason for it not to have the plug-in.

I'm interested in any and all opinions. If you are interested in becoming a part of this effort, please drop me an email.

Thanks,
M. Warble
m.warble@xxxxxxxxxxxxxx

.



Relevant Pages

  • Re: Confirm my Performance Test Against Java?
    ... absolutely horrible design - nothing to do with any type of language, ... I worked on a project that had more than 100 developers building ... I was a bad/intermediate C++ programmer when I learnt Java. ... The significance of a technology change depends upon how its used, ...
    (comp.lang.ruby)
  • Re: A problem statement (and a proposed solution)
    ... PHP programmers aren't even *close* to the market Lisp should be ... The comparison that frequently gets drawn is between PostgreSQL and ... early releases of Java JDBC and MySQL. ... this seems quite self evident when you talk to other developers. ...
    (comp.lang.lisp)
  • Java the smart option for Business Intelligence
    ... Global business intelligence vendor Yellowfin is investing in the best ... available Java technologies and people to stay at the forefront of web- ... “One of our key strategies has been to embrace the best available Java ... developers run with the technology,” ...
    (comp.databases.oracle.misc)
  • Yellowfin says Java the smart option for Business Intelligence
    ... Global business intelligence vendor Yellowfin is investing in the best ... available Java technologies and people to stay at the forefront of web- ... “One of our key strategies has been to embrace the best available Java ... developers run with the technology,” ...
    (comp.lang.java.programmer)
  • Re: F9: Firefox: Java based site fails to work.
    ... > NoScript is not going to help you get Java working. ... you will probably have to install Sun Java in order to ... Once I sorted that out, I could not find an elegant way to turn off gcj; my first inclination was to remove it, but, that led to a request to delete about 25 other packages from my machine for dependencies - I stopped that. ... Then I tried to remove the plug-in from Mozilla - creating the linked file to the java, as suggested by one of the commands on that linked page, had already produced a message that the file existed, so I suppose that libjavaplugin_oji.so was being used by gcj; I renamed that file and then ran the link command again - that appeared to be successful and produced the appearance of Sun Java in the plug-in list in Firefox; but, the gcj plug-in was still there, and attempts to use the ATT Relay site continued to fail; then I renamed a second plug-in in the mozilla plug-in folder called libjavaplugin.so - that didn't work, because it was simply a link to another *.so file somewhere I suppose, so gcj continued to appear in my plug-in list in Firefox - finally, I just created a folder inside the Mozilla plug-in folder called 'old' and moved the now renamed files 'libjavaplugin_oji.so.gcj' and 'libjavaplugin.so.gcj' to this folder, and that finally solved the problem. ...
    (Fedora)