I first met Scott McNealy on Thursday afternoon, February 8, 2001, at about 12:15 in the afternoon. Not that I was keeping track or anything. But I was starting to teach a new Java course that night, based on curriculum I’d created, so the timing was particularly striking to me personally. McNealy was the CEO of Sun Microsystems, creator of Java. McNealy was the featured speaker at the National Press Club’s luncheon that day. I’d brought a couple of professional colleagues and friends to meet him.
The Java programming language was already important to Oracle systems, which was why my company was launching the new course. Our company, db-Training, already taught coursework in Oracle development and database administration. We were very early to recognize the significance Java would have to the Oracle database. There was a key architectural similarity between the two products that was rare among the various competing products of the time. I’ll explain.
The Oracle Relational Database Management System (RDBMS) wasn’t – and isn’t – just a database. It’s an operating platform. This fact cannot be overstated, especially to those who haven’t worked with Oracle. The RDBMS stores data and houses software snippets, in a container that can operate on any operating system. So if you created a database application in the Oracle RDBMS – and I did, quite a few of them – you could do so without a concern for what operating system your application may end up running on. The trick was that you just moved the application into a version of the RDBMS designed for that new operating system.
But if you created a database application in, for example, traditional COBOL or FORTRAN or something else, you had to concern yourself with the operating system in which you were going to execute the program. Is it Microsoft Windows? Which version? Is it Unix? Or something else – an Apple computer of some sort? For each new environment, you would have to recompile your FORTRAN or COBOL or whatever program, being aware that the compilation may result in errors, even if it had compiled perfectly well on another operating system already.
With Oracle, you didn’t have to bother with that nonsense. Create your app in the Oracle database, and you’re done – it’ll work on any operating system, you just have to move the app to the appropriate RDBMS.
However – you couldn’t use FORTRAN (well, ok, you could, but just go with me on this, you Pro*Fortran people). You had to use an Oracle proprietary language called PL/SQL.
I love PL/SQL. I love it so much, I wrote a book about it.
Then along came Java, and its Java Virtual Machine. I think Oracle Corp was quick to realize that the JVM was to Java what the Oracle RDBMS was to database applications – a buffer between the Java program and the operating system, which meant that you could write a single application in Java, and then move it from operating system to operating system by swapping your existing JVM with one that fit the new operating system. You didn’t have to recompile or rewrite code. You just had to do a one-time installation of the JVM at the new location, that’s it.
Just like the Oracle RDBMS.
When Oracle acquired Sun Microsystems, a lot of conspiracy theorists rolled their eyes and figured Oracle would destroy Java somehow. I was pretty confident Oracle wouldn’t do that. It made good business sense for them to support Java.
I was there at Oracle Open World when Scott McNealy spoke. You could tell he was impacted powerfully by the acquisition of Sun by Oracle. I don’t think it was his preference, but rather an economic necessity. I’m sure he would’ve kept Sun independent if possible. But since he had to sell, Oracle was the best way to go.
And now – history has shown that Oracle has been very good to Java, according to InfoWorld.
I could’ve told you that years ago. Oracle needs Java. It was a good fit, and still is.