Java EQEmu

[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]

Originally Posted by mattmeck

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.

Originally Posted by vales

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.

Originally Posted by 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.

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]

Originally Posted by Elysius

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]

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.