A Java parable

Once upon a very long time ago in a universe called Sun Microsystems, James Gosling and a project named "Oak" emerged (1991).   In 1995, Oak became Java and "write once, run everywhere" came upon us.  Like virtual worlds - Java started with a big vision.  More than a programming language.  Like virtual worlds it became part of the idom of a networked world.  It is now eleven years old and Java SE 6 is here.  The journey to this point, is a parable for the likes of virtual worlds, perhaps...

In 1995 the idea of platform independence was infectious: why were computer programs so hard to write?  Part of the problem was that for every machine, differences in the underlying operating system, devices, and hardware had to be reflected in the program and its preparation (compilation, deployment, etc.).  That was a lot of bother (and expense) if one had many different machines.

What Java brought to the table was a streamlined object-oriented (OO) language, a network street-smarts, and a Java Virtual Machine (JVM).  The idea behind the JVM was for you to write your program for this virtual machine rather than the underlying real machine: the JVM insulated your program from the vagaries of your "real world" computer (fn1.)

However, for this to work, there needs to be many different JVMs - one for every kind of host.  Each JVM would look the the same to each program, yet each JVM would be created uniquely for an underlying real platform.    Work still had to get done for your program to run on all these different real machines, but the beauty was that it would happen outside of your concern.  By localizing the worry to those who implemented virtual machines, it meant that the (*much larger*) programming crowd that wrote programs for those virtual machines, well, didn't. 

By and large I think the programming language and platform called Java made the world a better place.  Though perhaps its success did not translate into the profits that Sun hoped for, nor certainly the technical home-run many of the early visionaries believed in.   And yes, the purists still grumble.

Sure, browser-based applets turned to a retreat, but on the server Java did flourish.  Yes, the poetry of "write once..." came to mean something more prosaic.   And too, the simplicity of Java 1.0 grew into a forest of J2EE, J2ME, JSP, JNI, Java 3D, JAI, JDO, JDBC, JNDI... to name a few of the extras.  Perhaps this is the price of an umbrella:  you need a bigger one to fit more people beneath it.

Eleven years on there is greater maturity in the Java community and its role. It is more of a practical community than it was in 1995 (less evangelistic).  These days we see a deeper self-governance in the Java community.  There is a Java Specification Requests (JSRs) process.  Furthermore, Sun has said there will be an Open Source Java SE later this year.  Times have changed.

To a careful Terra Nova reader, this tale so far may appear as a metaphor for at least a few virtual worlds and some of their evolution.  Perhaps the evolution of technology and its relationship to people whereever it occurs follows a common pattern.

There is one aspect I wanted to dawdle my last remaining cycles this evening.  In Guess My Game (fn2.) I tried to cap a running discussion we've had over the last year or so as to the nature of virtual worlds relative to their representation in source code.  A subtext has been whether scripting suits virtual worlds.  Think of user-created content (Second Life) and user-modified UIs (World of Warcraft).  Yes, games have had a long tradition with scripting for good engineering/business reasons:  modding communities; managing the separation of concerns of programmers and level designers, etc.   But do such hooks poke holes in a unified world view?

Java SE 6.0, interestingly, has scripting language support.   From here you can see about two dozen or so scripting engines developed (so far).  Thus, an interesting element of Java 6.0 lies not at its center, but at its edges. There is utility in an improved Java but utility is not necessarily excitement: there is excitement (for me) in the exotic mashups.  Consider Jaskell.

If you think this sounds really arcane, you are right.   But this brings me to my conclusion.  In 1995 there was a tight vision about a streamlined language that could write once and run anywhere.  At the end of 2006 I am salivating Jaskell. 

Does a big umbrella suggest the maturity of a platform (fn3.)?

As I mentioned earlier, Java is apparently turning to Open Source.  In fact, an announcement was made in Second Life (see here), of all places.   The symbolism is rich, though I wonder the conclusion, eleven years from now.  And yes, I wonder too of your virtual world.

-------------------------------------------------------------------------

fn1.  /Ed 12.16.  As some of the comments point out - it is worth noting the distinction beween different types of virtual machines.  The JVM, by this taxonomy, would be considered an application level virtual machine.

fn2.  See also "Tooling Around."

fn3.  Btw, see the TIOBE Programming Community Index for December 2006: "...gives an indication of the popularity of programming languages."


Comments on A Java parable:

Michael Chui says:

I think the most pointed parallel of this is the comment that Java should have gone open source two years ago. The comment applies just as well to virtual worlds, in my opinion.

Posted Dec 13, 2006 11:59:27 PM | link

Greg says:

Um.

J2EE rules the financial world. J2ME is important in mobile, at least until handsets that run native OSes are widespread. J2SE? Since MS's decision not to support Java out of the box, most users are faced with a scary "you must download something else" message before they run Java apps.

Don't misunderstand; I heart Java as a language. But desktop Java has been essentially abandoned by everyone except those who can enforce what goes onto a user's machine (read: corporate PCs).

But I think there's a lot to be said for J2EE on the backend and Flash or AJAX on the front-end... without any necessary user exposure to Java at all.

As for games--screw interpreted language. You want access to the machine level, as low as you can go, for performance reasons.

Posted Dec 14, 2006 12:50:20 AM | link

Ben Gimpert says:

Provocative, but definitely misleading. The only reason Sun is (finally) open source-ing Java is because the GNU CLASSPATH and gcj projects have caught up. Sun has no choice.

Java did *NOT* "bring to the table" virtual machine technology. The portability improvement resulting from a clean layer of abstraction over machine code -- bytecode -- is at least as old as 1966 and Pascal-P.

There are many other cracks in the facade of Java's greatness, so I believe the metaphorical use with MMORPG's is stretched. Java was a fantastic marketing success, and very little else. (Albeit JIT compilation is kinda neat.) I'll naively believe that a MMORPG's success is driven more be quality, than the size of its shelf in the Borders computer section.

Posted Dec 14, 2006 3:55:43 AM | link

Andrew Crystall says:

Greg, um.

ONLY when you're throwing graphics on the table as a performance issue. There are plenty of games - there are some really quite popular java board games (Megamek being the first example which pops into to my mind), for example - where graphics simply are not an issue.

Posted Dec 14, 2006 6:13:51 AM | link

Mike Rozak says:

Like virtual worlds - Java started with a big vision. More than a programming language.

Java was intended to be an OS within an OS.

In 1995 there was a tight vision about a streamlined language that could write once and run anywhere. At the end of 2006 I am salivating Jaskell.

As Ben Gimpert says, Pascal had this idea long before Java.

Though perhaps its success did not translate into the profits that Sun hoped for, nor certainly the technical home-run many of the early visionaries believed in.

The purpose of Java was to make Windows irrelevent, the theory being, that if an application could run on any OS, then the OS would be valueless. This would hurt Windows and (hopefully) prevent Microsoft from producing a server OS (aka: future versions of Windows NT) that could compete against Sun's unix. Java didn't work as planned. Sun has basically been finished off by a combination of Windows NT and, more importantly, Linux. (IBM and others pushed Linux because they wanted BOTH Sun and Microsoft to lose.)


But there is excitement (for me) in the exotic mashups. Consider Jaskell.

In the grand scheme of MMORPGs, a scripting language is an easy thing to write. I wrote my own, with IDE, in a few months. I agree that a domain-specific language is potentially useful, but whether it has its origins is Java is moot.

Most MMORPGs seem to use Python or Lua, which are small and free. They're not ideal for simulating worlds, but then again, most of what's in a MMORPG is eye candy and database; relatively little scripting code. If you want to see a well-designed domain-specific language, look at the latest Inform, designed for producing interactive fiction... and only interactive fiction (as defined by Inform/Infocom).


Greg wrote: As for games--screw interpreted language. You want access to the machine level, as low as you can go, for performance reasons.

For eye candy, yes (kind of), but not for server world simulation. When you do the financial math, code that runs 1/10th the speed of C++ takes 10x as much hardware, but hardware is (relatively) cheap. Hiring coders to write C++ (which is more difficult than python/lua), and testers to debug C++ (which has pesky memory overrun problems and crashability), and the inability to modify code on the fly, and the extra time-to-market for all of this, far outweighs the cost of extra hardware.

Posted Dec 14, 2006 6:34:18 AM | link

lewy says:

Check out Bruce Tate's _Beyond Java_ from O'Reilly Books. His argument is that Java has had its ten year run and something new and better is inevitable.

Posted Dec 14, 2006 10:09:23 AM | link

Endie says:

To tie the subjects of Java and VWs even closer together, Multiverse's server plugins (the bits where you write the elements that really define the way the world and its occupants behave, as opposed to the scripted elements of individual mobs, spawns and the like) is coded in Java. I've been having some fun with that myself recently (written up here and in later posts).

Posted Dec 14, 2006 11:32:57 AM | link

Trevor F. Smith says:

As an aside, Simon Phipps at Sun is looking into opening Java3D for more than research use. With a nice all-in-one plugin installer and some serious 3D hacking at Java3D's core we might have a usable, cross platform, in-browser, 3D platform.

Posted Dec 14, 2006 3:46:05 PM | link

DLacey says:

Ben Gimpert: "Albeit JIT compilation is kinda neat."

Yes it is, but it too predates Java. VisualWorks Smalltalk had it before Java came out, which is where I first saw it (according to Wikipedia this is where it was pioneered).

The whole "write once, run anywhere there's a VM" worked perfectly in VisualWorks, for reasons that actually made VisualWorks not acceptable to many customers - the buttons, check boxes, etc were all implemented on top of the VM, not using the operating system versions, so they didn't work or look identical to the ones that were native.

Early Java applets had this problem also.

You could perhaps draw parallels to how UO had a lot of features that later virtual worlds didn't, because of the drawbacks they brought along. But I can't ;)

Posted Dec 14, 2006 5:09:14 PM | link

juha says:

The only reason Sun is (finally) open source-ing Java is because the GNU CLASSPATH and gcj projects have caught up. Sun has no choice.

You must be joking. Show me a single mission critical application that runs on Gnu Classpath and gcj. Please.

Java was a fantastic marketing success, and very little else.

The rest of the world disagrees. Most businesses are utilizing Java today in one way or another in their server room. There is no serious contender in the middleware space today.

Posted Dec 16, 2006 6:48:54 PM | link

Ben Gimpert says:

juha: "Show me a single mission critical application that runs on Gnu Classpath and gcj. Please."

This is totally irrelevant. Every single hip, new thing is considered bizarre and risky for the first few companies that adopt. That's where Sun's incredible marketing comes in; it eases the effort in recruiting developers with the right skill set ("where will we ever find coders who know WhizBang?"), the marketing also nudges uni's into using the language in CS programmes, etc.

And the "rest of the world" (umm, you) does not disagree. VBA is still the most popular programming language. Frameworks like ZOPE and Rails are good server-side soluations, while C# is a decent rip-off technology for Windows-only server environments. Having been a professional -- self-loating, apparently -- Java developer for ten years, Tate and I are very ready for something new.

You must dig through the marketing to unlearn what you have learned...

Posted Dec 17, 2006 6:05:52 AM | link

juha says:

This is totally irrelevant.

It is very relevant to your bogus claim that Sun needs to react because of increased adoption of GNU Classpath and GCJ. These projects have been around for years and they have zero penetration in the enterprise. Therefore Sun's actions have nothing to do with them.

VBA is still the most popular programming language.

I never made a claim that Java is the most popular programming language in the world. I'm pretty sure it is in the top three though ;-) However, VB is used for desktop applications (when not replaced by C#). Java today is the market leader on enterprise middleware.

Frameworks like ZOPE and Rails are good server-side soluations

They may work for you but that doesn't change the fact that they have a tiny fraction of the market share compared to Java. Zope and RoR make hardly a blip on the radar. And there are very good reasons why that is but it undoubtedly will turn to a long conversion that doesn't belong to this forum.

Having been a professional -- self-loating, apparently -- Java developer for ten years, Tate and I are very ready for something new.

Good for you. Go have a blast. However, the reality still remains the same. Java has been incredibly successful on the server side, and today has no serious contenders as the middleware platform of choice for large enterprises.

You must dig through the marketing to unlearn what you have learned...

I don't need to dig through any marketing. I see the reality of Java adoption on a daily basis in my job. The world's largest companies are using Java middleware -- and given the amount of investments they have made this is not going to change any time soon. You clearly have no experience in what goes on inside the IT departments of the world's largest companies today, or you are willingly closing your eyes and ignoring it. It's Java -- not VB, Zope or RoR.

Posted Dec 17, 2006 6:52:46 AM | link

Ben Gimpert says:

These projects [GNU CLASSPATH and gcj] have been around for years and they have zero penetration in the enterprise.

The default installations of the Debian and Fedora Linux distros include the GNU Java projects. This has been the case for some time. So even without trying, these projects have far more than "zero penetration."

During a previous project, our infrastructure folks forgot to install a Sun-blessed Java run-time on one of our Linux servers. The only reason we noticed -- days later! -- was because the performance was a bit poor. (Again, JIT is kinda neat but not new to Java.) Here I admit to confusing the availability of binaries with their actual use in "enterprise" software, but I hope this is somewhat forgivable given Java app's notoriously complicated deployments. (Can anyone here configure a J2EE container in less than twenty-three thousand man weeks? If so, please send me your CV. ;-) )

Yes this is anecdotal, but you are vastly underestimating the penetration of GNU projects in the enterprise. This is especially pointed given that grid systems ("100 cheap Linux blades") are the next hip thing (i.e. not just Google). Do you find Sun's timing -- not their marketing, but their actual decision making -- a bit suspicious? It's not like their marketing has ever been misleading before...

Besides, I am not asserting that the current adoption of GNU Java has sparked Sun's (finally!) Open Source-ing Java. It has nothing to do with current adoption, but everything to do with the hundreds of eyes now staring at an open, decent implementation of the Java API and a JVM-ish system. It is just a numbers game; there is no way GNU Java will not (at least) catch up with closed Java, just as gcc has (at least) caught up with closed C/C++ compilers. Sun knows their Java community is very Open Source friendly (thank you, Jakarta), and could very well jump ship given the real option. (See "jikes and Eclipse.")

I think we're conflating two issues; one is the reality of how Java is used in the "enterprise" now-a-days, versus the promises and marketing of the Java platform extolled by Sun through the 90's. This distinction is worth making, because Nate's original post talks about the idealisms of Java, and asks us to consider these ideals as a metaphor for the development of some MMORPG's. This could still be applicable, but it ain't for technical reasons.

I agree that we needn't dig up the stale and ancient debate of Algol-ish languages like Java versus more Lisp-y languages like VB, Python and Ruby. This argument will never go away, and doesn't really matter anyway.

You clearly have no experience in what goes on inside the IT departments of the world's largest companies today, or you are willingly closing your eyes and ignoring it.

Well that's a bit harsh. Obviously you don't know me, and might be utterly baffled by the skepticism with which Java "marketing speak" is met with in my industries (City of London finance and consultancy). At least a few of the world's biggest trading firms and banks -- and thus some of the world's largest IT shops -- talk about simplifying over-architected 90's systems with (Java) tools like Spring & Hibernate, and talk about using more "scripting" languages like Ruby and Python for the client and server side glue.

Yes, just as we still write C++ and maitain COBOL code, the world's investment in Java means it's not going away. However, I predict (there's that word) Java development becomming a lot more competitive, pragmatic and Open Source. In other words, less Sun-centric. At least we'll get JDK bugs fixed a helluva lot quicker.

But again, we're not really progressing this topic. Nate's post seems to talk about metaphor -- a comparison between the development of one technology (Java) with the development of another, completely different technology (MMORPG's). As an overall metaphor, I think it's totally misleading and hence my de-lurking.

Anyone coding on the server-side of MMORPG's care to talk about their experience with Java, or with more modern platforms like C#, Rails or Zope?

(PS -- I don't work for Microsoft, or for Sun, or for any of the Rails zealot consultancies. Any more.)

Posted Dec 17, 2006 10:11:24 AM | link

Rafhael Cedeno says:

I'm using Java on the server side. C# is probably a better language than Java, but if you're looking for cross-platform support, it seems Java is more mature on the Unix side of things than Mono is. For instance, Mono has only recently added generics support.

JIT compilers have come a long way. Since this happens at runtime, it can theoretically be faster than precompiled code.

The constant factor runtime performance of you code doesn't always matter that much. Most CS undergrads are supposed to learn that it's the "Big-O" that really matters. If you write your bubble sort algorithm in assembly, and I write my merge-sort/quicksort in Ada (or insert whatever language you think sucks the most), mine will beat yours with a large enough problem set. The thing with MMOGs is that we have really large problem sets, with several N-squared, or worse, problems which needs to be addressed. What this means is that how your system 'scales' matters more than how fast it runs. This largely depends on your design and algorithms.

An area this is usually apparent is when you scale your platform to multiple machines. Some platforms dont allow you to this at all. In this scenario, if Ironforge, for example, gets too crowded, then you just have to buy a bigger machine to run it. In other geographically scalable solutions, you have inefficiencies introduced with each extra machine you add. Probably because there are communications overhead in managing the servers or overlapping geographical areas between servers (so that you dont have obvious server transition borders). It doesn't matter why, it comes down to how efficiently the system scales. A system that runs on C++ but has a 50% effieciency is going to lose over a Prolog based server with 90% efficiency pretty fast. My feeling is that current platforms have radically differing efficiencies and scaling capabilities.

If youre dealing with a small world with a few hundred people, it just doesnt matter much. But if youre dealing with a few hundred thousand, then how the platform scales will matter a lot more.

I don't quite understand the comment about Pascal being like Java. C# and Java allow you to write your code that can interact with the OS in a platform neutral way. A few years back we used to use NSPR to do the same thing (a runtime library developed by Netscape for C). Try writing some Pascal code that can send and receive UDP packets, create threads, and do thread-level locking and signaling. Let me know how that goes.

Posted Dec 18, 2006 1:25:55 AM | link

Ben Gimpert says:

I heartedly agree with Rafhael that BigO analysis (should) pervade our thinking about scalability, but I think there is a class of algorithms ("solutions") that may not be as efficient but are easier to parallelize. In other words, more SMP and grid-ish hardware architectures might mean I'd choose a "n(log(n))" algorithm over just "n" if (and only if) the n(log(n)) is easier to split across a bunch of CPU's.

Actually, I brought up Pascal because a certain flavor of that language had a portable bytecode and API long before Java and C# were on the scene. (See "http://en.wikipedia.org/wiki/UCSD_Pascal".) I'm not sure about thread-level locking, but the whole TCP/IP stack and signals were definitely there. Just another of my "there's nothing new in Java" slants. ;)

Posted Dec 19, 2006 4:19:54 AM | link