Java: A platform for platforms
Sun's reorg may seem promising to shareholders but it's also a scramble for position. The question now is whether Sun can, or wants to, maintain its hold on Java technology. Especially with enterprise leaders like SpringSource and RedHat investing heavily in Java's future as a platform for platforms

Also see:

Discuss: Tim Bray on 'What Sun Should Do'

Featured Whitepapers
Newsletter sign-up
View all newsletters

Sign up for our technology specific newsletters.

Enterprise Java
Email Address:

Sever-side Java: Software engineering on Internet time

Developing on Internet time still requires strong software-engineering principles

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone

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.

  • Digg
  • Reddit
  • SlashDot
  • Stumble
  • del.icio.us
  • Technorati
  • dzone
Comment
Login
Forgot your account info?
Add comment
Anonymous comments subject to approval. Register here for member benefits.
Have a JavaWorld account? Log in here. Register now for a free account.
Resources

Server-side Java: Read the whole series -archived on JavaWorld