huibert-aalbers.com

It is hard to believe, but Sun Microsystems released Java 1.0 almost 20 years ago, on January 23rd, 1996. I was an early adopter because I was intrigued by the write once, run everywhere promise. At the time, developing for the Mac did not look like a viable career option and yet I did not like the idea of having to switch platforms. As a result, Java seemed a great option.

Java 1.0 couldn’t do much beyond producing animated content for the browser, but it was easy to learn, mostly because it had so few libraries available at launch. In fact, this was part of the excitement, as so many basic building blocks had to be created in order to allow other developers to build more powerful applications. As an example, during Java’s early days I wrote a GUI for applets (Swing didn’t exist and AWT sucked), inspired by the classic MacOS toolkit. I called it MAE for Java. It was a lot of fun.

Over the next few years, Java grew up. In 1997, version 1.1 added JDBC and the servlet standard, which paved the way for the application server era. I discovered WebLogic at the second ever JavaOne event in San Francisco and even though the product had limited capabilities at the time, it was clear to me that the concept had a lot of potential. Java was quickly becoming a solid platform and a serious contender in the Enterprise world. Over the following years, the J2EE spec (now simply known at JEE) continued to mature in order to address an increasingly large array of IT requirements (SOA, Web development, encryption, MQ integration, O/R mapping, etc.). For those of us who got on the bandwagon early, adopting these technologies was easy. We just had to learn a couple of new APIs each year, a pace which, with hindsight, now seems quite reasonable. Everything was great. So great in fact that I credit Java for developing a whole generation of IT Architects. I am of course talking about senior professionals who usually have somewhere between 15 to 20 years of experience, not the kids just hired out of school by consulting firms and labeled “Architects” to justify higher hourly rates.

So, how can someone become an architect today? It all starts by learning the right programming language. Some languages, like Visual Basic (let’s use a dead language as an example to avoid offending anyone), are great for quickly building specialised solutions, but won’t help you with your career. I for one have never met a CTO or CIO who got his/her job after a successful and gratifying career as a Visual Basic programmer. On the other hand, Java was designed from the beginning as a general purpose language, designed to build any kind of application. Sun Microsystems, which was on a mission to conquer the world, wanted their language to be used for everything, from embedded systems to large distributed enterprise applications. To achieve that goal, they enlisted most of the IT industry leaders (IBM, SAP, Oracle, etc.) to help them provide Java developers with a large selection of rich, stable and supported APIs as well as solid developer tools like Eclipse. The results achieved by this broad industry alliance have simply been amazing. Twenty years later, no other computer language comes even close to the level of versatility Java offers today. Engineers who grew up with Java got progressively exposed to a large number of technologies which allowed them in turn to grow their own career and eventually become Architects or CTOs.

Despite Java’s undeniable success, something weird started to happen somewhere between the releases of J2EE 5 (2006) and JEE 6 (2009). People started to label Java as “heavy”, “complex” and “hard to learn”. Sure, the fact that Oracle bought Sun in 2010, adding fear and uncertainty to the future of the platform, did not help, but this trend started well before the acquisition. Learning Java was becoming increasingly hard for beginners. In my opinion, this doesn’t speak ill of Java, but it does raise some serious questions on how we should teach complex platforms to beginners, an issue we definitively haven’t solved yet. That said, perception is reality and interest in Java started to dwindle, despite the success of Android.

Over the last few years, countless new programming languages have appeared and are now fighting for our attention. Some are great, others not so much. The problem is that, in order to become viable alternatives to Java, specially in the enterprise, these languages will need to mature. Even if the language itself may not have to evolve significally, the plaform will need to grow. In order to solve complex problems, new APIs will have to be built and over time these platforms will inevitably become as complex as Java is now.

I am not saying that we shouldn’t try to replace Java with a better alternative because complexity will inevitably creep into any successful development platform, on the contrary. A better programming language with a strong API library could be a significant boon for developers. I absolutely believe that a better programming language can make us more productive. However, adopting a better language does not make complex projects significantly simpler. You may be able to use less lines of code to achieve you goal, avoid potential errors or even simplify the development of multithreaded code, but in the end, hard problems remain hard to solve and require experienced professionals that can design complex systems. A better language is great but it is pretty much useless if it does not have the APIs enterprise developers require.

I would love to have a true alternative to Java. It would be great if I could use a modern non-propietary language such as JavaScript, Go, Rust or Swift to write any kind of system. However, none of these great languages will become serious contenders in the enterprise unless we give them the opportunity to mature. This requires strong stewardship and industry support. That is why my money right now is on JavaScript as the most likely successor to Java, specially now that the technology is backed by industry heavyweights IBM and Microsoft. That said, JavaScript has still a long way to go before it can compete with Java, and that concerns me. The main problem we face right now is the limited attention span of the developer community. We tend to jump too quickly from one hot technology to the next one. Hadoop has been red hot for the last few years, but now Apache Spark seems to have taken a lot of wind out of it’s sails. In the relational database space, mySQL seemed to be about to take on Oracle and DB2, but now interest in open-source RDBMS is waning in favor of multiple No-SQL databases (Cassandra, MongoDB, CouchDB, etc.). If the developer community does not stand strong behind JavaScript for several years, Java may not have a successor and young developers will not have a chance at building a successful career in enterprise IT.

For now, Java is still among the most popular languages out there, with a stable marketshare, but the situation is quickly changing with long time favorites such as C# and Objective-C quickly losing steam in favour of newcomers like JavaScript and Swift. Java is still very strong in the enterprise, but interest in that language is at an all time low among those who want to learn programming. If we want to build a new generation of IT Architects and CTOs, we need a replacement for Java and we can’t wait for another 20 years.

Yesterday Oracle updated their Java JRE to fix yet another zero-day exploit. It seems that lately Java has become the new Flash, with new exploits being found on a daily or weekly basis. It really looks like they are dropping the ball on the security aspect of Java. This is specially upsetting since the whole idea of Java was built on security from day one, yet since Oracle acquired SUN it is obvious that the situation, far from improving, has gone downhill ever since.

It is true that Java has become a monster. I recall the early days were all you could do was perform simple animations on a browser, but there was no standard way to connect to a database. Those days are long gone, and now there are zillions of APIs to do almost anything you can dream of in Java. That is a strength of the platform, but also a weakness, as it is becoming harder and harder to spot bugs. I do understand, and it may be time to remove some APIs from the platform, but it doesn’t have to be like that. There are alternatives to the Oracle JRE and not all are affected by this bug. For example, IBM’s JRE does not have this bug. That is because IBM spends money to harden the security of its own product. It can therefore be done, it is just a matter o spending additional time and money on quality testing. My issue is not that there are no better options available, it is that Oracle’s failure to secure Java is casting a long shadow on the future of the platform, and all of us who have invested in it.

I think it is time for Oracle to clean their act. They have always to solve their problems through heavy marketing spending? Remember when they advertised their database as being Unbreakable? That, obviously wasn’t true. Their product wasn’t sub-par, but it hardly was above the pack, specially if you compare it to DB2 on the mainframe. The same can be said for their applications, which require regular fixes, which address serious security issues. Marketing, allowed them to enjoy a reputation they didn’t deserve. Now they have to deal with reality. I think this is something new for them. The only way out is to invest in their product and solve the issues. In other words, more engineering and less marketing. Otherwise, Java will go the way of the Dodo.

Disclaimer, I have always worked at companies that have competed with Oracle. However, this is personal, these problems do affect me and my career directly, as well as hundreds of thousands of fellow Java developers.

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.