Skip to main content ↑ ↓
Topic: Simutrans in JAVA? (Read 12503 times) previous topic - next topic

Simutrans in JAVA?

Off topic: That's  also a reason why I like Java - it's much easier to keep applications "going" there than in C++

This topic was split - the new title says "Simutrans in Java" but I originally only wanted to express my like for the Java language, and not an intention to code Simutrans in Java. While we discuss now if this would be possible, I'm more or less still only defending the Java language from some misunderstanding and prejudice, and have no plans or whatsoever to program Simutrans again in Java.
 

Simutrans in JAVA?

Reply #1 –
If we do a Java port someday I'm in again. Working on C++ code isn't that easy anymore when you have Java all day ;)

Simutrans in JAVA?

Reply #2 –
I've been dabbling in C for a bit recently, and I just don't want that anymore. Java is so much easier ...

Simutrans in JAVA?

Reply #3 –
Well but Simutrans code cannot go to JAVA, as it is more OOP than JAVA allows, like multiple inheritances all over the place and such.

Simutrans in JAVA?

Reply #4 –
I know ... just dreaming. And also explaining a bit of my problems to get in touch with C/C++ based project again.

Simutrans in JAVA?

Reply #5 –
Multiple inheritance is bad :).

Simutrans in JAVA?

Reply #6 –
C++ doesn't have interfaces, so you need to use normal inheritance to gain the same effect. And seldom things are just bad or just good - multiple inheritance can be useful but bears dangers and good programmers know when not to use it.

Simutrans in JAVA?

Reply #7 –
Why? As used in SImutrans it workes quite nicely.

Like any object can be a ding_t and a steppable_t for animation. Why is this bad? It reduces code like
Code: [Select]
if(  dynamic_cast<factory *>(obj)) {
  factory *fab = dynamic_cast<factory *>(obj);
  if(fab->is_steppable()) {
    fab->sync_step();
  }
else if(  dynamic_cast<vehicle *>(obj)) {
  vehicle *veh =  dynamic_cast<vehicle *>(obj);
  if(veh->is_steppable()) {
    veh->sync_step();
  }
} ...

As with any tools it depends on how you are using it. You can also use electricity for electrocution or defibrillator ...

And I fear the JAVA garbage collector would suck on the several millions of objects on larger maps.

Simutrans in JAVA?

Reply #8 –
I can't imagine how slow that Simutrans would be in Java...
Download Simutrans-Extended.

Want to help with development? See here for things to do for coding, and here for information on how to make graphics/objects.

Follow Simutrans-Extended on Facebook.

Simutrans in JAVA?

Reply #9 –
Java isn't that slow anymore ... but for Simutrans most likely still to slow. I'd ****ume a Java based Simutrans reaches about 30% of the performance, but would be much easier to multithread, and that could be a win on new systems.

Simutrans in JAVA?

Reply #10 –
Sorry, it wasn't intended that you take my statement so serious. Fact is that it has advantages as stated and that it is a chance for severe mistakes if not used carefully. Java avoids it and uses interfaces to get it done.

And yes Java is far better than it was with version 1.3 (this was the version I got in contact with it and it was real slow), but a up to date Java version is not comparable to this. Also the garbage collector is better now than it was before (you can also control its behaviour if you want).

I ****ume UI and other graphic stuff would be easier and cost less performance than now??


Simutrans in JAVA?

Reply #11 –
On Unix (X-Windows), graphical operations in Java seem to be pretty slow. At least I got some feedback about my Java based applications that indicates so. On Windows Java uses the DirectX libraries which are fairly fast.

UI in Java should be much simpler than in current Simutrans (but that is not a fault of C++, but a Problem of the UI implementation in Simutrans, which was not designed for such complex UIs as Simutrans has them now - originally it was only for small windows with a few buttons).

Simutrans in JAVA?

Reply #12 –
UI costs very little performance in simutrans and is currently quite flexible. In fact it is a little like the UI in BeOS, one of the very few completely object oriented UIs. In that aspect it is very different from most other UI I know.

A garbage collector is slow. Also it adds quite and overhead. Just imagine a 24 byte structure; the GC needs to add a size field and an access timer. It needs for any acces to record that it is still used. Making it in the best case 34 Bytes. And remember, simutrans uses its own memory management, since even standard malloc was more than 30% slower. I doubt any garbage collector comes close to malloc/free, so I doubt JAVA simutrans will run at more than 10% of its speed.

And how does the GC know about stones in the upper left corner not visited for some years and completely deleted objects? And since the number of objects is not known beforehand, one ends up with the same arrays of objects, only slower and bigger. (Not to mention the route search, which even do not use any allocations at all. I could go on about the route search.

In the end it could be done in JAVA, but for many things similar hacks would be needed (like a fixed size array for goods routing with structs equivalents) if it would end playable.

Re: Simutrans in JAVA?

Reply #13 –
This topic was split - the new title says "Simutrans in Java" but I originally only wanted to express my like for the Java language, and not an intention to code Simutrans in Java. While we discuss now if this would be possible, I'm more or less still only defending the Java language from some misunderstanding and prejudice, and have no plans or whatsoever to program Simutrans again in Java.

You can use memory/object pools in Java, too. It need some thought and care by the programmer, but it's not rocket science either. This will make gc much more efficient, and is the Java equivalent to Simutrans' selfmade memory management.

But yes, there is an overhead for gc ... I think 8 to 12 bytes overhead are a reasonable ****umption for each object. And it has to check the head for garbage now and then, but it does this very efficiently, and usually in less than a microsecond, unless you have created really lots of garbage. Object reuse and pooling can avoid that.

There are several gc implementations available in Java 6, and one can choose which to use. All are fairly complex, and so I cannot tell in a sentence or two how they work. I can only say they are not so dumb and slow as it seems to be ****umed here. I'm working with Java since 12 years now, and I see big improvements in the language. I know it can't challenge C or C++ for the most performance needing and realtime systems, but for the average application Java is really good.

I prefer to code Java these day. I like the language much - not for speed, but for the ease of writing and ease of debugging. I choose and tailor my projects so that they work with Java.

I want to conclude that Simutrans is better done in C++ and shall stay C++. I didn't want to put doubt in there, nor did I want to challenge that. I'm sorry if my writing appeared to say so.


I want to quit this discussion here. I made my choice, others made theirs. We are happy with our choices, and so it's good. No need to be missionary, and make other people feel bad about their choices. I'm sorry that I brought this up.

Re: Simutrans in JAVA?

Reply #14 –
I'm curious.Java and C++ are more or less similar so making a rough estimate, what percentage of Simutrans code could be port to Java as it is, with their equivalents in Java, and what percentage would need to be hacked or rewritten? 60-40? 70-30? 50-50?

Re: Simutrans in JAVA?

Reply #15 –
I heard of tools that help with the process, but I have no experience with those.

I have ported C and C++ code to Java in the past. In case of Simutrans I'd ****ume more than 70% of all code lines must be adapted, if doing it manually.

Each pointer declaration and each pointer dereference operation must be adapted, that uses to be the biggest work (search-and-replace can help to some extend, but the * symbol is also for multiplications. so search-and-replace only helps so much).

Simutrans uses value objects in places, which Java just doesn't have, and replacements must be found.

As Prissi noted above, Simutrans uses multiple inheritance in a style that Java does not support - only one parent cl**** can be a normal cl****, all other parents must be pure virtual cl****es (interfaces in Java). That will require a number of architectural changes.

Java templates are different from C++ templates, but I cannot really estimate the impact.

Simutrans also uses "plain" memory areas, allocated by malloc IIRC. In Java such do not exist, the closest are arrays. Each array access is type and bounds checked, so those are slower than memory accesses and a poor way to emulate plain memory areas - in order to get good performance this requires architectural changes again.

My past experiences with porting foreign C and C++ code (= code that I had not seen before) to Java are saying that it takes fairly long (1-2 hours for about 1000 lines of code, if the code is not black magic code), and usually it ends with poorly performing code. To make it work well, a deeper redesign is needed, which needs even more work, but very often just fortifies the opinion that Java is slow, because suchlike ported code really performs poorly. In Java one would use different designs from start, end up with a different application structure and if done right, and code that can get withing the reach of 50% of C++ performance.

I want to repeat that I do not want to port Simutrans to Java, not even suggest to do so. I just like the Java language and was expressing facts that I particularly like among it. For example the fact that Java programs can be written easier in a manner to avoid fatal crashes, also easer debugged than C++. I did not want to challenge C++ overall, it has it's merits. Java has different benefits, which overall matter more to me, and thus I made Java the language of my choice. Speed of execution was not among those.

Re: Simutrans in JAVA?

Reply #16 –
The current implementation is very heavy on multiple inheritances and so. It also uses a lot of pointers as hashes and unions of pointers and arrays so there are changes needed too. Lots of abstract cl****es and templates.

It can be done, but my feeling is that about 30% of the files need more than just slight changes. But better ask a person better knowing in Java than me.

Re: Simutrans in JAVA?

Reply #17 –
You tempted us too much so now there's not turning back, Hajo. We demand a java port...  :D

Re: Simutrans in JAVA?

Reply #18 –
No.

Re: Simutrans in JAVA?

Reply #19 –
Do not tease Hajo, please.

No seriously, if started again, Java might be a good choice. Others than that simutrans working fine now, and it is portable enough, so why should work put be in for almost no gain in the moment?

Re: Simutrans in JAVA?

Reply #20 –
Thanks, Prissi! Also, I'll try to avoid bringing up the Java topic anymore. I'm sorry for that.