I love Java. A large part of my success as a software developer over the last decade is due to the fact that I was an early Java adopter. Java also allowed me to grow professionally and become a Software IT Architect at IBM. Over the years I have written many J2EE web apps, some J2SE applications and even one Java2ME program for a Sony-Ericsson handset. The fact is that I am totally convinced by the many benefits of Java and I do not feel attracted by any other language to write enterprise web applications. But seriously, Java for the iPhone? Why?

On the server, J2EE is extremely appealing because it is an open, scalable, secure technology that allows developers to create complex solutions. If you plan to integrate all kind of legacy systems or develop true robust distributed systems Java simply has no competition.

On the desktop, the situation is quite different. Sun Microsystems tried to create a platform that would allow developers to create applications that would work on any OS. Their first attempt at providing a common GUI was the AWT. It was a complete failure because it only allowed to use controls common to all existing platforms. Complex controls such as trees or tables could not be used because even if they existed on Windows or the Mac, they were not available on other OSes such as QNX. The second attempt, an API usually known as Swing (or JFC) tried to solve the problem by avoiding native widgets altogether. Instead, each component was drawn in Java, bypassing the OS. This move allowed Sun to support complex controls on any OS. However, the first release of Swing was painfully slow and a memory hog. As a result, most developers have avoided the technology despite Sun’s efforts to improve it in subsequent releases. The problem is that every time the Look and Feel of an OS is updated, Swing needs to be updated also, to ensure that widgets are drawn properly. IBM proposed a better solution, called SWT, used in Eclipse and many other Java applications. Instead of hand drawing all controls, SWT uses native controls when available and draws them manually as a last resort. The result is a more efficient API that produces much better results. Even so, users normally can quickly spot Java desktop apps because they simply do not look native. This is specially true on the Mac. While PC users seem to have no problem at all using Java applications such as Azureus, Mac users seem to prefer non Java alternatives such as XTorrent or Transmission. To make a long story short, those who designed the Java strategy for fat clients assumed that all GUI were similar and that any differences were merely cosmetic. It was a terrible assumption that was made well before Apple migrated from OS 9 to OS X (which makes heavy use of transparency and animations) by people who could not envision how technologies such as hardware accelerated graphics would impact GUIs. The result is that very few still consider Java as a viable option for creating desktop applications.

On a phone, the situation is even worse. Developers don’t really know what to expect from a Java capable phone. There isn’t much standardization and capabilities vary significantly from one phone to another. The main benefit of Java2ME on a cell phone is that it makes migrating applications from one cell phone to another relatively easy. This is specially true for mobile games that do not require a standard user interface and where all the display is handled by Open GL.

The iPhone is a device that lies somewhere between a computer and a phone. It has an amazing user interface that users expect applications to fully embrace. Java currently does not offer any solutions to work effectively with that aspect of the device. However, Java could still prove useful to help quickly migrate all those games written for other handsets to the iPhone. Is this important for Apple and iPhone customers? I doubt it. With over 100,000 SDKs downloaded in just over four days, it seems that the iPhone will not lack native software (including games). The announcement made by Sun that it plans to make Java available for the iPhone is mainly targeted at existing J2ME developers. The company run by Jonathan Schwartz wants to open a new market for their software development partners to prove the value of J2ME by making it easy to sell old content on a new platform.

Until now, only large companies could negotiate with telcos to get their content on the carrier’s phones. The margins were razor thin and to make any money you needed to get your content on millions of phones. Supporting multiple brands of handsets was a necessity and in that context, Java was a blessing. The announced App Store is leveling the playing field. Now everyone can sell mobile apps. With 70% of the price of the software going straight to the developer, it makes sense to develop applications specifically for the iPhone.

On March 6th, Apple invited mostly large companies to show the software they were working on at the iPhone software roadmap event. However, you will see that by late June, when Apple releases version 2.0 of the iPhone firmware, most of the applications available through the App Store will come from passionate independent developers that will try to get out the most out of the device, not companies trying to obtain incremental revenue from something written years ago. In fact I predict that many large companies specialized in developing software for mobile phones will find it difficult, at least at the beginning, to compete against many of the enthusiasts who will create innovative solutions at home during their spare time.

I abandoned Java on the desktop for Objective-C years ago because Cocoa allowed me to get the most out of the Macintosh platform. The same applies to the iPhone. Objective-C is similar to Java in many ways. What makes the difference is Cocoa touch which is a great development framework and allows to get to the guts of the iPhone without compromises. That is why I personally don’t care if Sun releases a Java SDK for the iPhone or not. I am quite sure most of those 100,000 developers who have downloaded the SDK agree with me.

As I briefly mentioned in my previous post, I recently flew to Chicago to attend an internal IBM Rational kick-off event. As a technical manager at IBM I lead the Software Group IT specialist team in Mexico, which includes engineers who belong to the Rational brand. Therefore I need to know in what direction the organization is moving.

As a long time software developer, Rational has always been intriguing to me. I have worked on many complex projects, sometimes alone (when that was still possible back in the 80s and early nineties) and more recently leading small teams. I started programming at age 14, and sold my first commercial application for the Apple II four years later. Being a good programmer did not help me with my first engagement as a consultant, though. Even thought I had already published three commercial applications in the U.S. at the time, that did not prepare me at all for the job. I can say with no hesitation that the project turned quickly into an absolute disaster (it was riddled with typical project management issues, which I was unable to anticipate). I learned a lot from the experience though, and have been able to avoid making the same mistakes ever since.

Rational has a great value proposition. It offers to train IT organizations in how to effectively implement a development process that should allow, in theory, to avoid most of the common pitfalls these organizations encounter daily. That process, RUP (Rational Unified Process), is the result of collecting the experience of thousands of teams who have worked on both successful and unsuccessful projects. Although, as many developers, I am personally allergic to any kind of process that stands between myself and my IDE, I have to admit that many of the failed projects that I have witnessed could have been executed successfully by implementing a decent process. I have found in particular that most programmers fail to properly garner requirements and effectively test their applications. Rational is specially strong in both disciplines and I like that.

So, if implementing a process is so beneficial why do few organizations actually do it? There are many explanations. Junior developers simply do not understand that they need to do it. Experienced developers are sometimes arrogant and think that they can live without it, not understanding that the code lives on when the application is finished and they move to other projects. Someone else will have to maintain the application and expand it. They will need proper documentation, test sets and tools to keep track of the changes. However, in my mind there is an additional reason. In many cases, those who sell methodologies too often have not written any line of actual code in years.

This is a problem as it creates a strong credibility issue. How can a Java programmer trust the recommendations of someone who does not even know the language and wrote his last COBOL application ten years ago? That happened to me when I went to my first Rational conference. I thought, well they may be right, but why should I trust them, after all they are no longer programmers. Today, I have realized that they do not have to be programmers. Their recommendations apply to any software development project, no matter what the language or the architecture is. However, I still feel that there is a strong technology gap between those who focus on methodologies and those who actually do the programming. That is why I am working on making sure that my Rational IT Specialists become fluent in Java and interact more with the WebSphere team. Credibility is key, no matter how good the service Rational sells.

Software vendors like to talk about innovation. They usually mention their R&D budget as a proof of their commitment to creating new exciting technologies. However, the truth is that most large companies are turning to A&D (Acquisition and Development) strategies to quickly incorporate new ideas into their products. Buying startups that have developed new ideas and proved their value at a small scale in the market seems to be cheaper than maintaining large labs which produce inconsistent results.

However, even with shrinking research funds, large companies have been able to set the pace of technological innovation. In the enterprise for example, it is hard to believe that the Web Services revolution could have occurred without the large investments made by companies like IBM and Microsoft. The same goes for BPM (Business Process Management). Something similar happens on the desktop, where most innovations seem to come from Apple and to a lesser degree Adobe and other smaller companies.

So, where is the innovation within the open-source movement? The truth is that I do not really see it. The engineers that work on open-source projects seem to focus on doing things faster, better and cheaper (with mixed results). That is great but I would like to see more innovation. Take for example the just released Firefox 2. Take a look at the new features offered in this release. You will find new exciting features such as Inline spell checking, RSS support and much more. Not excited? You are not alone. Most of these features are already available elsewhere. If you want real innovation in browser technologies you better look at companies such as Flock, OmniGroup or Opera.

Do not get me wrong. I love open-source software. I am an avid Firefox user as well as an Apache Foundation fan when it comes to looking for solid Java or C APIs for my applications. However, I really believe that if the open-source movement really wants to take over commercial software companies it needs an improved value proposition. Faster, better and cheaper is good, but it is innovation that get people excited.

Ten years ago, I had just joined Informix and represented the company at a customer event. I had been hired because of my web experience, and although I had decent SQL experience, I had never worked in highly complex environments. So, when a customer asked if he required a product like Tuxedo to manage his transactions I looked to him straight in the eyes and said, Absolutely not! That will just add to your project complexity. The product I am presenting will handle this automatically.

Why could I say that, well because at the time I believed it. Technically the product could manage distributed transactions, but only if all the involved databases were Informix databases. The truth is that I had some doubts and checked the facts as soon as I went back to the office. I never repeated the mistake.

Why do I write about this today? Day after day I hear people claim facts that are just not true. Sometimes it may be a honest mistake, hey it happened to me, so why can’t it happen to others. But, having worked many years with salespersons, I really suspect that more often than not, people are just repeating buggy marketing messages without checking the facts, because they simply don’t know, don’t care or even worse, doesn’t serve their personal goals.

I am not really concerned about the lies most salespersons tell, I tend to think that it is part of their job description. I am really more interested in the professionals who highly recommend technologies without knowing or checking the facts. Fifteen years ago you could find developers saying that you didn’t need a relational database, since FoxPro was more than enough for all your enterprise needs. Today, it seems that many of these same people have adopted mySQL and are criticizing those who use products such as DB2 or Oracle without realizing that there are significant differences in availability, scalability and administration features. The same happens with PHP or Ruby developers who talk down Java. I can understand that not all projects require high-end products (which sometimes means expensive) but I cannot accept that people who do not understand in depth both technologies try to demonstrate the supremacy of the one they are familiar with.

This post was triggered by an episode of Podcast.net in which someone was basically saying that Java was obsolete and that everyone should now move to PHP because it is much simpler than Java. This is simply ridiculous. PHP cannot solve many of the problems that we face daily at IBM, like developing embedded applications for cell phones or PDAs. PHP is not a competitive EAI solution, nor does it allow to create client/server applications. That does not mean PHP is useless. I can see some developers choosing PHP over Java to create Web applications or to develop the front-end to an enterprise application, but that’s it.

There is a say in Mexico that says that if you repeat a lye a thousand times, it becomes the truth. This may be true, but it doesn’t help. As a technical person I want to use the best tools for each situation. I do not want ignorant people to drive the technology. The web has made it easier for everyone to publish their opinions. The problem is that the majority is not always right.

Even with Apple, a company I really do like a lot, because of their ability to simplify complex tasks, there are many times where they clearly over-hype a technology and end-users echo the message without checking the facts. Take for example the remote control that comes with most new Macs. Sure, it is simpler than the ones that come with Windows Media Center, but for now, you cannot really compare the functionality that both products provide. The same applies to iWeb, which is a simple application for beginners but does not meet the need of professional web designers or programmers.

We all want to have simple solutions to complex problems. However, sometimes, complex problems call for complex solutions, like it or not. Therefore, we may have to occasionally take the long, hard road. In some cases, we may find an easy solution to a complex problem, but this is not usual. If a company offers something that looks much better than everyone else is offering, make sure there are no drawbacks. Listen to the competitors. They may know something you don’t.

I have spent most of the week working closely with a customer who was complaining about their J2EE application performance. Normally it goes like this. The customer calls their sales rep and starts complaining about their application server performance. They usually threaten to move to application server from company A or company B if we do not fix the problem immediately. The fact is that since I have been working with J2EE application servers, in 100% of the cases, it is the application that is responsible for the performance problems, not the application server.

IBM has published some very good documents that explain what needs to be done to obtain the best performance from a J2EE application server. Although those documents focus on WebSphere Application Server, most recomendations apply to all J2EE servers. Go to http://www.redbooks.ibm.com and search for “websphere performance”.

However, if you do not have time to read a full book, you should at least read the article “10 (more or less) J2EE best practices“.

My own recommendation, on top of what the article lists, is to limit the creation of new objects in your code. Always check if there are no other alternatives, such as object reuse. My recommendation is to always apply strict scrutiny when new objects are created and always assume there is another way to do it. Use static methods when possible, but make sure that junior programmers are not instantiating objects in order to execute the static methods (a very common mistake).

Advanced Java IDEs such as Rational Application Developer will automatically detect these problems and mark them with warnings. Do not ignore them just because they are not errors that will prevent the code from running properly. Make a habit to produce code that is totally bug and warnings free. That is the best way to avoid all kind of problems.