Java EQEmu

[qbvbsite]

Hey,
Has there ever been talk about taking the current EQEmu and porting it over into Java? The reason I ask is that its total multi-platformable and i think there are more developers that would know java then C. Also by porting it over it gives you a chance to redo some of the old code and structuring it a little better. I don't know what kind of responce i'll get from this but i was thinking of maybe doing this in my spare time and if anyone was intrested just give me a shout.

--James

[mattmeck]

uumm LOL, ROFL...

Sorry but this is just a funny idea.

[Scorpious2k]

Java just plain isn't fast enough or powerful enough to do what the server does.

On the other hand, C++ is multiplatform...

[qbvbsite]

Hey,
C++ is multiplatformable but need special compiling under windows and such, to me Java is more universal... and Java just is plenty powerful enough to do the job. May not be as fast as C but its still pretty fast. I would be quite a fun project to do.

--James

[wize_one]

so how fast is java to read through over 100megs of database info.. process it send that info to the client.. all while you have 5-300 zones running as well as handling connections from 1 to 500+?

i agree with matt.. LOL

[myrrddyn25]

i think you should go ahead with your project and ignore their imature flames, ive used several different languages honestly i dont see that there would be much speed difference, to those who decided to be rude to this poor guy... mysql REGUARDLESS of the language accessing it it will only go as fast as mysql goes genius' perhaps you should think before making yourselves look the fool publicly? if coded properly any language COULD be multi platform however as previously stated compiling on windows is quite a pain in the ass to be honest. I have seen PUBLIC Games ( GEMSTONE FOR ONE) That are indeed written in java and do the same crap as eq and twice as fast so dude ignore them or prove them wrong... i doubt they even know how to code java anyway...

[John Adams]

Agreed. It's probably not necessary to be a dick to the guy for an idea. Takes guts to ask, anyway. But I do agree, Java is not exactly lightning-bolt speed compared to other languages. It really comes down to what you know, how much interest you have in your project, and whether you can stand on your own to get it done - cuz it's apparent you won't get too much input here. Not insulting our devs at all, but they have their hands full with the current code as designed.

Good luck, should you proceed.

[qbvbsite]

so how fast is java to read through over 100megs of database info.. process it send that info to the client.. all while you have 5-300 zones running as well as handling connections from 1 to 500+?

i agree with matt.. LOL

Accually java can do the above quite fast, currently at my place of work we push about 30-40 mbs of database data into objects (called Beans) in about 10 seconds. Also once there in memory its much faster to access the data and send it to the client. For all the zones and the client connections this is all done by threads and is really just limited by your hardware and not the coding language. I would recommend that you do some more research before you make a flame post like that, I do like constructive critizim but please back it up with some facts next time.


Java just plain isn't fast enough or powerful enough to do what the server does.
Again I would like you to back this quote up. I know java isn't the fastest language but it does have some benifits that C does not (like not needing to compile it special for windows/unix).

Agreed. It's probably not necessary to be a dick to the guy for an idea. Takes guts to ask, anyway. But I do agree, Java is not exactly lightning-bolt speed compared to other languages. It really comes down to what you know, how much interest you have in your project, and whether you can stand on your own to get it done - cuz it's apparent you won't get too much input here. Not insulting our devs at all, but they have their hands full with the current code as designed.

Good luck, should you proceed.
i think you should go ahead with your project and ignore their imature flames, ive used several different languages honestly i dont see that there would be much speed difference, to those who decided to be rude to this poor guy... mysql REGUARDLESS of the language accessing it it will only go as fast as mysql goes genius' perhaps you should think before making yourselves look the fool publicly? if coded properly any language COULD be multi platform however as previously stated compiling on windows is quite a pain in the ass to be honest. I have seen PUBLIC Games ( GEMSTONE FOR ONE) That are indeed written in java and do the same crap as eq and twice as fast so dude ignore them or prove them wrong... i doubt they even know how to code java anyway...
Thanks for your guys post it's nice to see a post that isn't a flame.

By no means i'm i dissing the dev's here, they are doing an awesome job. This was just an idea I thought would be cool and wanted some input on. I must admit I didn't expect all the flames but its all good. Either way i think i'll be doing it as a little side project because alot o fthe code will be similar in another project im correctly working one (Network and database layers). If anyone has anymore input on the idea feel free.

--James

[Teppen]

Emulated servers using java are do-able, for instance, UOX3 an ultima online emu converted their c scripts to java scripts which they claim are faster. But you really cant compare an mmorpg like UO to EQ, EQ's alot different in many ways. Besides we already have a working EQ emu, which is hella better then ashrans piece of poo emu if anyone remembers the birth and fall of hackerquest.. why create another eq emulator just because this one isnt in java, or why port this project to java when this one works just fine? Im actually glad that the eq emulator scene hasnt turned the UO or WoW way where there are like 12 or more emulators per mmorpg and none that are up to par because everyone in those groups want to have their own emu, and its very disappointing that they dont band together and make an awesome emu like eqemulator. One emu! one db! Nuff said!

Do I hear an Amen?

[mattmeck]

Quoting several sources here from a simple google for java vs C++

The biggest potential stumbling block is speed: interpreted Java runs something like 20 times slower than C. Nothing prevents the Java language from being compiled and there are just-in-time compilers appearing at this writing which offer significant speed-ups. It is not inconceivable that full native compilers will appear for the more popular platforms, but without those there are classes of problems that will be insoluble with Java because of the speed issue.

Java uses a singly-rooted hierarchy, so all objects are ultimately inherited from the root class Object. In C++ you can start a new inheritance tree anywhere, so you end up with a forest of trees. In Java you get a single ultimate hierarchy which is very restrictive.

[quote]No inline methods. The Java compiler may decide on its own to inline a method, but you don

[Arex]

I only want point that L2j (Lineage 2 emulator) is done with Java. I have tried it L2j emu, and it goes fast and it looks stable...then not say that Java isnt a good language for develop a emu.. On other hand, the eqemu already is very advanced, then it would be a loss time port it to other language without any visible benefit.

[vales]

I've developed a bit for L2J, and I although the project is pretty solid, it's still java which hurts it in the long run. Sure, it's fine for a handful of people playing on the server, but once you have more people log on, it goes downhill very fast. It simply cannot handle that many instructions and users at the same time. And till this very day, it still suffers from the same issue. Now some may argue that java is the internet coding language to use, but you really can't base a game structure on it. It's just not efficient enough no matter how good at java you are.

When I got my hands on the C++ version of the Lineage 2 server, it was infinitely better. It can handle thousands of people online, and since you're using a SQL database structure, it's quick and fast. No lag, and more options to edit the database without having to sift through tons of java scripts just to edit one item. Even though L2J has migrated to the MySQL structure, it still has issues. There's just some coding language that gets lost through the transition, and most of the time, it breaks it even more.

Why do you think that the L2J dev team uses the C++ server's coding to help them along? I'm sure they won't admit it (since it draws a fine line on whether or not it's legal), but it's there as proof on their forums. They're even using the geodata structure from the C++ server files to try and squash the Z axis bugs that L2J suffers from. Did you ever run through some of the areas on the L2J server? Mobs are underground and even fall from multiple levels in dungeons, ignoring all Z axis information. On the C++ server, the mobs act accordingly since the geodata structure is there, plus you have the pathnode files. Not to mention you can edit the geodata in the game now so no more dodgy geodata. L2J is just catching on, I'm sure. Maybe even using the tools for the C++ server as I type this. Of course I'm pretty sure they're not going to come out and admit it. :) But I don't see any possible way for them to just ignore it. The tools are there - they just won't show their interest in it. And don't even mention it there. They'll lock the topic in a heartbeat, which I have no problem with. They're only protecting their best interests, after all.

There's even some projects that attempted to convert the Lineage 2 java code to C and it ran much faster, given it was missing some vital codes - they're all on sourceforge by the way. Check if you don't believe me. :p It's been a while since I last checked, but I beleive it was called L2JC or L2C.

I don't mean to bash on L2J. It's the whole reason what got me interested in all of this. Lineage 2? Java?! Sweet! It was almost too good to pass up. It was fun when I was into it full speed, though I have to admit. But I just got tired of the crashes and moved on to better things.

And before anyone gets an itchy finger to PM me, I want to just say that I'm not about to give out the server files for Lineage 2 since it's a pretty sensitive subject. So don't even bother asking. It's not technically illegal since it was distributed by NCSOFT's internet provider in China, but it draws a fine line here in the states. If you want it, then do your own research. :p But I didn't type out the four paragraphs above this one to blow smoke out of my bum. It's the plain truth, and I speak with experience from both ends. I don't claim to be a coding guru, nor do I really care. But after I broke the structures down and played both versions, it's really a no-brainer.

I just wanted to give my two cents for the topic. That's all. If people want to code in Java or whatever they want, let them. It's not about which is faster or better, but what makes anything worthwhile is the challenge of it all. :) But since the subject of L2J came up, I had to say something.

Uh, carry on then. Don't mind me. I'm just an old man with nothing better to do at 5 in the morning, lol.

[qbvbsite]

There were points that were made that made it better then C++ however the speed issue is the one that craps this idea.

mattmeck i thank you for your quotes. I did know about the other 2 quotes (about inline compiling and the inheritance) and for what I cant do with multi-inheritance i can do in interfaces (may not be as good as multi-inheritance but gets the job done). As i stated before I do know that C++ is faster then Java but i dont think that it craps the out the idea. If this subject were to come out a few years ago there would be no arguement because Java was slow. Over the past serveral years Java has gotten better and faster. Plus im not doing this for speed or to make it better then EQEmu (because its already an amazing product) I was just thinking it would be a nice project to attempt. But maybe my effort should be geared toward the current EQEmu but who knows.

I just wanted to give my two cents for the topic. That's all. If people want to code in Java or whatever they want, let them. It's not about which is faster or better, but what makes anything worthwhile is the challenge of it all. But since the subject of L2J came up, I had to say something.


Thanks for you input :). Like you said in your quote its not about if it faster or better, its the challenge of it all.

I only want point that L2j (Lineage 2 emulator) is done with Java. I have tried it L2j emu, and it goes fast and it looks stable...then not say that Java isnt a good language for develop a emu.. On other hand, the eqemu already is very advanced, then it would be a loss time port it to other language without any visible benefit.
Like i said to the last quote its all about the challenge and plus it would be fun. Im not coding this to replace EQEmu i just thought it would be cool to attempt.

With all the reponses I have gotten maybe it would be more benifical to work on the current EQEmu then making a Java port. I dont know what im gonna do but i'll let you guys know. I dont know C++ nearly as much as I know Java but I have to start some where I guess. If you start to see C++ code poping up on the fourm you will know what I desided ;)

--James

[Elysius]

Thanks for you input :). Like you said in your quote its not about if it faster or better, its the challenge of it all.



No offense, but maybe it might be a bit better to do a challenge that will actually improve upon the emu?

[qbvbsite]

No offense, but maybe it might be a bit better to do a challenge that will actually improve upon the emu?

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.

[Elysius]

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]

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]

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.

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.


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.

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.

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!!)

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.