Programming Language Progression
As computing platforms shift (see Figure 2), languages of choice shift as well. While Cobol dominated the mainframe and minicomputer eras, the client/server era may have presented developers with the most language options. Developers could choose from a number of popular languages, including Microsoft's Visual Basic, Borland's Delphi, PowerSoft's PowerScript, and others. These languages were all essentially somewhat-typed, pseudo-interpreted languages. And they were all replaced with Java, a strongly typed, pseudo-interpreted language and Visual Basic .NET, a somewhat-typed, pseudo-interpreted language.
During the Internet era, organizations ran a variety of server operating systems in the middle tier, including Solaris, AIX, HP-UX, Irix, and Windows NT. In many companies, a strong requirement was that applications be portable across two or more platforms to avoid being locked into a single vendor. If an organization's applications only ran on one platform, the organization lost much of its bargaining leverage and the vendor could price gouge in the next upgrade cycle.
Java was originally designed to run on set-top clients and then on PC clients, so the language and its runtime were designed to be portable and undoubtedly met this goal. Using servers from NetDynamics and KIVA, some companies had already started running Java on the server. In addition, Java offered some of the benefits developers enjoyed in languages from their client/server days, such as garbage collection and higher level APIs to operating system features that abstracted complexity.
Java soon gained a critical mass of vendors who supported the platform. Everything under the sun soon had a Java API, including Oracle, SAP, Tibco, CICS, MQSeries, and so on. Over a couple of years, these applications and services were all accessible via standardized APIs that grew into J2EE, which went on to dominate the corporate computing environment of the Internet era.
What Java failed to provide was 4GL-type tools. However, no other language had 4GL-type tools for web applications, so their absence was no surprise. Unfortunately, years have passed, and the vast majority of J2EE applications are still built by hand. A lesson that Microsoft has learned is that for APIs to be toolable, they need to be developed concurrently with the tool. Moreover, both APIs and tools should depend on easily externalized metadata. Java APIs were always written on the merits of the APIs themselves, and subsequent tools were predominantly code generators shunned by programmers.
The Java APIs grew into a morass of inconsistent and incomprehensible APIs. Programming even the simplest application proved to be complicated. According to Gartner, more than 80 percent of J2EE deployments are servlet/JSP-to-JDBC applications. That is, the vast majority of these applications are basically HTML front-ends to relational databases. Ironically, much of what makes Java complicated is the myriad of band-aid extensions, such as generics and JSP templates, which were added to simplify development of such basic applications.
Despite these issues, Java and J2EE have come to completely dominate the Internet era of corporate computing. These technologies will remain dominant until companies begin their migration to next-generation grid architectures and their related languages.
