Do you enjoy history? I do. In fact, I've always enjoyed history for I've always found that understanding the past has been useful in helping me to understand the here and now. Part of my here and now is the taking on of the role of enterprise editor. The question for me is, how did I get here?

When I look back at my career, I realize that my choices have allowed me to be closely aligned with many aspects of core J2EE technologies for more than 15 years. Yes, I do know that J2EE has not been here for 15 years, but when you look past that exact moment in time when the idea for J2EE was first hatched, you can see a vast trail of technology and research that has gotten us to where we are today. My interest in history has led me to follow that trail and, as is the case with most historical tales, I was taken by surprise by just how far back you need to travel. Take the virtual machine, for instance.

In 1965, a team of engineers working for IBM first devised a virtual machine so they could study multiprogramming operating systems. What they meant by virtual machine at that time was a duplicate of the actual machine they were testing on, but the VM had less memory. If you think about the Java Virtual Machine, the definition is just about the same. Okay, there's not a real Java machine per se, but the JVM does have less memory than what is available in the underlying hardware/OS.

From these raw beginnings came Dijskstra's work, where he built an operating system by layering a number of VMs on top of each other. Each VM was an abstraction of some underlying portion of the OS. What followed was yet another improvement by another IBM team, which resulted in the creation of the VM/CMS, a time-sharing OS for the IBM 370. Right around that time, Alan Kay laid the groundwork for Smalltalk, considered to be the de facto standard for OO technologies. This brief paragraph is only the tip of the iceberg of the research and development that really started in the late '50s. Just from this little bit of history, we can see through the marketing hype and understand why Java is not just a language - it truly is a technology platform.

Legend has it that Bill Joy conceived of the principles behind Java in the late 1970s, but it wasn't until the early '90s that the necessary ingredients came together to make it a reality. Even as early on as the late '70s, Smalltalk, Lisp, and a number of obscure languages had already been operational for a number of years. The difference is that Java is really the first commercially successful language/platform to support distributed computing. From this success came the realization that to truly bring distributed computing to the masses, they would need help putting it all together.

The help first came in the form of the Enterprise JavaBean application server. I'm unaware of the true origins of the application server but I have worked with one for more than 10 years - GemStone for Smalltalk (GS/S). GS/S is generally recognized as an awesome collection of technologies. It was supported by an orthogonal transactional persistence mechanism that was instrumental in its support of distributed computing. As good as the technology was, people had difficulties understanding it. Though you could think of it as an object database that relied on a proprietary Smalltalk implementation, it was really more than just that. It was just when I started working for GemStone that I made the jump to Java. GemStone had begun the process of porting their Smalltalk technology to create an early version of a Java application server. Again, GemStone was ahead of the curve as they were working without a specification, so they defined a distributed component model based on JavaBeans. Not long after the initial implementations of GS/J went to press, the EJB spec appeared and everyone started the race to implement the latest features in the latest specification. After 15 years in the business, the appearance of the EJB specification provided GemStone with a means to describe their technology.

I began my journey in a world that was as aware of the possibilities of Java as it was unaware of its absence. The journey has been exciting as I've been able to work with a number of world-class engineers who were implementing the latest bleeding-edge technology in a market that was still trying to figure out what it wanted. Yet, in all of that confusion, we have been able to define and build a technology that is pretty solid. It has let us mere mortals build systems that would have been unthinkable only a few years ago. But in this ever-changing game of cat and mouse, the cats (our users) continue to adjust their expectations and demand even more complex systems so we still have plenty of problems to solve. Having said this, maybe there are hints to the solutions to these new challenges somewhere in our collective past. Certainly, we should take the time to look for them.