Server-side Java: Software engineering on Internet time

Developing on Internet time still requires strong software-engineering principles

For several months in 1999, I worked primarily on the backend of a Web-based, ecommerce project. Almost all project software was implemented using Java and server-side Java technologies, including servlets, a homegrown version of JavaServer Pages (originally developed before a stable version of JSP became available), and JDBC to connect to and communicate with an Oracle database. There was even a touch of XML, but its use was limited, since the mainframe software-processing customer orders were XML-illiterate.

The development team worked long hours and weekends to meet unrealistic marketing-driven schedules, but it was an exciting time, and no one seemed to mind the extra time commitments. In fact, it was the most exhilarating, fun-filled software project on which I have worked, mostly due to the use of Java and Java-related technologies. In retrospect, I learned two general lessons -- sort of a good news/bad news story -- that I would like to share:

  1. This Java stuff really works.
  2. Software engineering on Internet time is extremely difficult.

This Java stuff really works

In my former programming lives, I have used a number of languages extensively. In fact, I can label each of the various periods of my professional career by its dominant programming language -- the FORTRAN years, the Pascal years, the Ada years (Ada-83, not Ada-95), the C++ years, and now the Java years. Each step along this path was marked by a new programming language that was both more powerful and, until Java, more complex than its predecessor.

I found both Ada and C++ to be very complex, but when they were introduced into my career, their power more than compensated for the effort needed to master the complexities. Still, I found both languages lacking. For example, neither language supports reflection, and both have only minimal standard libraries when compared to Java. I have also constantly struggled with issues of object ownership and memory management, especially with C++; these issues are addressed directly by Java's automatic garbage collection. I was particularly disillusioned with Ada when I tried to apply it on a real project where reuse was important. At the time, I didn't fully understand the nature of my frustrations, but I recognized that Ada-83, while supporting reuse better than such earlier languages as COBOL, FORTRAN, and Pascal, still came up short in its support for reuse. Something was missing. I later found those missing features -- classes as user-defined types, inheritance, polymorphism, and so forth -- in C++; but C++ started out as a complex language and went on to spawn a plethora of even more complex features and constructs whose interactions made the language very difficult to use.

1 2 3 Page 1
Page 1 of 3
How to choose a low-code development platform