Java EQEmu

[Elysius]

Originally Posted by qbvbsite

The challenge is to code it and not to out do EQEmu because it is a great product that probably can't be beat except by the real thing.

So you want to spend hours upon hours recoding EQEmu to make it... crappier? What I'm saying is why not spend those hours fixing the many small problems EQEmu has?

[InsaneWallaby]

Java, eh? Mmm, a touchy topic...couldn't resist posting on it myself.

I noted that many pointed to Java being up to 20 or 30 times slower than C++. Eh, I would have to beg to differ on that statement. In the beginning, that was VERY true of Java--the 1.0, 1.1 and such JDK's were absolutely awful, and I agree 100% on those previous statements of Java being awful in these regards. However, quite a bit has changed since those times. Since the 1.4 JDK, Java has been much better suited than before. Now, J2SE 5.0 (the 1.5 JDK) is much more advanced and much more powerful.

Java seems to be a big hit in the universities, and as a computer science and mathematics student (I was previously meteorology and CS, but changed majors), I've noticed that instructors seem to hit a great deal on Java. I can definitely see why--Java is quite friendly in some regards compared to C++, with features such as automatic garbage collection (if the coder programs well, mind you!) and a somewhat easier portability between platforms. It is also becoming more widely used within companies and organizations, which also is also another reason it is becoming more widespread. Because of that, I actually purchased a rather interesting O'Reilly book about Java containing information about Java 2D, Java 3D, Java audio features, and Java networking entitled "Killer Game Programming in Java" by Andrew Davison. Now, granted, I didn't really want this book for making games--I still chuckle at that thought, actually--but, it did make me realize that Java is more powerful than a lot of people think.

The first chapter of the book is largely meant for disarming critics of Java, and it has some good points. On page 2, he states that "J2SE 5.0, the current release, is typically only 1.1 times slower [than C and C++]." As he also addresses the terrible problems of Java before the 1.3 JDK--he also addresses the 20- to 40-times slower speeds of the earlier releases--I don't think he's just "sucking up" to his favorite programming language. However, I'm still not so sure on this one, but since I am just a student at the time, it is not my place to judge this remark. Regardless, while I can see that Java has it's capabilities, I know that handling of a full-fledged game such as Everquest would not be very good at this time. Simply put, C and C++ has been around since, what, 1978 and 1985 (effectively, due to dates of formal reference material becoming available, I believe), while Java became known in 1996. At the current time, Java is just not quite as mature as C++, and has not been worked with as much, especially since JDKs before 1.3 sucked like a vacuum. One good point the author also had was this, though--people originally resisted the shift to C and C++ for programming games because people believed that "C and C++ were too high-level for fast, efficient games programming when compared to assembly language." As we know, that was fortunately bunk. Thank goodness, because assembly language gets really annoying for programming.

Personally, I wouldn't be too surprised (Should Sun Microsystems keep chugging along on their Java stuff successfully) if Java programming becomes a great deal more prominent within the gaming community in the next ten years. But right now, I definitely believe something this big and this intense should be programmed in C++, and not in Java, even though I myself am a fan of Java over C++. It would likely be too sensitive of programming to do effectively at this time in Java's life, and reprogramming all the C done so far would be a royal pain, so my opinion would be to leave the programming as-is. Furthermore, there is still some speed impediment, even if taken at the author's speed. So, it really is more efficient at the time to program in C++.

[John Adams]

Originally Posted by Elysius

So you want to spend hours upon hours recoding EQEmu to make it... crappier? What I'm saying is why not spend those hours fixing the many small problems EQEmu has?

I'm convinced that most everyone reading this thread is missing the point. It's not to make Emu crappier, or even better, but more portable. I myself would never run a java Emu (been playing with the enb emulator in java, and it's total ass to be honest, though it is barely in it's infancy atm). I'm just not going to tell the guy he's retarded for wanting to try. If nothing else, it'll be a learning experience - and who knows, some who don't care about performance may find it useful.

[johane]

Originally Posted by InsaneWallaby

I noted that many pointed to Java being up to 20 or 30 times slower than C++. Eh, I would have to beg to differ on that statement. In the beginning, that was VERY true of Java--the 1.0, 1.1 and such JDK's were absolutely awful, and I agree 100% on those previous statements of Java being awful in these regards. However, quite a bit has changed since those times. Since the 1.4 JDK, Java has been much better suited than before. Now, J2SE 5.0 (the 1.5 JDK) is much more advanced and much more powerful.

Depends on what features you're looking at and comparing. The Hot Spot compilers do speed up code that's hit frequently a lot. And Java is becoming powerful, in the sense that fewer lines of code get more work done, but do not confuse power with speed, they're not the same thing.

Originally Posted by InsaneWallaby

Java seems to be a big hit in the universities, and as a computer science and mathematics student (I was previously meteorology and CS, but changed majors), I've noticed that instructors seem to hit a great deal on Java. I can definitely see why--Java is quite friendly in some regards compared to C++, with features such as automatic garbage collection (if the coder programs well, mind you!) and a somewhat easier portability between platforms.

I was working in University (between surgeries) when the big debate on switching from Pascal to Java was going on. The reasons for the switch were basically that pure proceduralism is more and more considered a niche for programming, and it is considered that someone who can make a semi-OOP language like Java work will be able to make a procedural language like PASCAL (or modern FORTRAN, or good ol' C) work anyway. It's also really easy to teach and to mark assignments, there is a much lower risk of students infecting the instructors with virus, and it's easier to use funky filters to check for collusion. Java also insists on consistent naming and "standardised" style. It's also one of the simplest threading models yet devised (almost exactly that used by Borland in Delphi/Borland Pascal), and there was a feeling that Students should be exposed to parallelism earlier than they were as we arn't using 8k memory 36bit machines anymore.

Originally Posted by InsaneWallaby

It is also becoming more widely used within companies and organizations, which also is also another reason it is becoming more widespread.

There are a few reasons for this:
1) Graduates know it, and hence are using it, as new graduates are cheaper than experienced people.
2) Sun, IBM and BEA all have interests in getting people to use their enormous stacks (frameworks).
3) It's quite good at some kinds of programs, such as big hairy web-apps.

Originally Posted by InsaneWallaby

he states that "J2SE 5.0, the current release, is typically only 1.1 times slower [than C and C++]." <snip> I don't think he's just "sucking up" to his favorite programming language. However, I'm still not so sure on this one, but since I am just a student at the time, it is not my place to judge this remark.

Firstly, as a student, it's your place to question everything. You won't have that luxury in the workplace, with deadlines, contracts and lawsuits breathing down your neck!

I think all sides are being a bit devious on the "C(++) vs Java" speed debate. The base language is pretty quick, unless your creating a lot of objects, at which Java is very slow. It's slow because of all the management going on, we have SecurityManager, ObjectManager and a heap of other management going on that just doesnt exist in C++.

A big difference is that Java has no equivalent of a C-style array, a slab of contiguous memory which we address by pointers. It is impossible for managed container classes to be as fast as the basic array, although Array is getting close. I can't comment on how well Generics address this, but the general rule is that a "container" made on the metal in C/C++ will always be faster than subclassing a generic Container.

It's kinda fair to compare the STL containers with Java Containers though. The STL can easily be used badly, causing code to suffer from "template bloat", and it suffers from being written "portably", so it contains tests for endian-ness for example. Similarly, Java Containers contain all sorts of hoops and whistles that slow things down by trying to promise correctness.

Originally Posted by InsaneWallaby

Simply put, C and C++ has been around since, what, 1978 and 1985 (effectively, due to dates of formal reference material becoming available, I believe), while Java became known in 1996. At the current time, Java is just not quite as mature as C++, and has not been worked with as much, especially since JDKs before 1.3 sucked like a vacuum. One good point the author also had was this, though--people originally resisted the shift to C and C++ for programming games because people believed that "C and C++ were too high-level for fast, efficient games programming when compared to assembly language." As we know, that was fortunately bunk. Thank goodness, because assembly language gets really annoying for programming.

That's a modern revisionist view of things. Back in the early days of PCs, we used ASM routines for graphics because the graphics drivers didnt exist, and when they did they sucked. A huge step forward was the Borland BGI drivers, not because they were fast (they were OK, but not blindingly), but because they provided a way to provide hand-tuned asm routines in a re-usable way. Turbo Pascal, and the Borland C++ Application Framework included how to write a BGI driver, and included the source for the BGI drivers so you could hack and tune them. Now we have clever graphics cards that understand very high level instructions. In the old day we had to draw lines by flipping bits across multiple bit planes, and anti-aliasing all had to be done by hand in ASM. So it wasnt that the languages were slow, but that the drivers sucked that parts of games were written in ASM. ASM also allowed you to write much more compact code, back in the days when 4M RAM was a high end machine.

The maturity of the languages is a non-sequitor IMHO. There are differences deep in the design of the two languages, and they'll never be truely equivalent for all classes of problems. I just can't see Java ever being better than C/C++ for fat-client MMORPGs simply because of the management overheads. To get around this you'd have to use custom ClassLoaders and stuff, which would lose you the biggest thing Java would buy you, the ability to almost completely eliminate "hacking" and cheating (apart from social engineering!!)

Originally Posted by InsaneWallaby

Personally, I wouldn't be too surprised (Should Sun Microsystems keep chugging along on their Java stuff successfully) if Java programming becomes a great deal more prominent within the gaming community in the next ten years.

Look at RuneQuest for an example of a successful Java based MMORPG. Shame Jagex are such a bunch of <insert biologically improbable form of self-abuse here>.

One of the biggest errors in the C++ vs Java debate is to compare J2EE with C++. J2EE is slow and bloated, and if done wrong (i.e. use CMP as Sun suggests it should be used) you end up with systems that are feature rich, yet need monster hardware, and a new compute node every 200-300 users. But J2EE also provides the key to using eXtreme Programming and makes code re-use almost trivial. It's great for certain classes of business problems, But I don't think it'll ever be a 1st choice for fat-client MMORPGs.

Here endeth the lesson.