Evaluating Java for Game Development

Jacob Marner writes: "A large independent university report has just been published that examines whether Java is useful for professional game development."

Comments

Conclusions...

[Unruly]

In contrary to popular belief, Java applications are in fact not much slower than C++ applications when they have been tuned for performance. A rough estimate based on the various benchmarks would say that tweaked Java code is a little slower than C++; typically 20-50% on the average, but this is hard to tell for certain because of the large variations in the speed seen in the benchmarks....

20-50% is "not much slower" ??

Say I had two programs, one done in all C++ and one done in all Java

Now, if these numbers are right, then the C++ program is up to TWICE as fast as the Java one... I think I know which one I'll be using.

Re:Conclusions...

[Zach Garner]

> Say I had two programs...

But you don't! Instead, you either have a Java one or a C++ one. You don't get to chose. It's the people developing the games that make the choice.

Two more conclusions from the article:
1. The slowdown is less [than 20%] in 3D applications.
2. There is a 65% increase in productivity.

In addition, this paper makes a note that Java is useful for games that are not tied to performance and for low profile games.

For these games, the decrease in speed is not important, but the amount of money spent on the project is.

We've long since passed the point where programmer time is cheaper than hardware time.

Re:Conclusions...

[mvw]

1. The slowdown is less [than 20%] in 3D applications.

Java3D is written in C/C++. Thus the Java program feeds the C/C++ layer with the necessary data and control, which in turn feeds the graphics processor, which does the work. The additional time is needed to transform Java Objects out of the VM into C Objects and back.

Is this bad? I don't think so. What I don't like is that Java is marketed as plattform independent, which it is not, large parts are implemented as native code. Java is easy to use on the 4 supported main platforms (Solaris, Windows, Linux, Mac OS X), otherwise one has to hope that a porting effort is underway (like in case of FreeBSD).

2. There is a 65% increase in productivity.

Most good Java programs I have seen yet are integrated development environments. It is really amazing how many IDEs are written in Java. Some of them being very good ones.

Add to this the large, standardized libraries, and the dumbed down syntax in many areas, compared to C++. While I judge 65% a bit high, development with Java sure is quite comfortable.

Re:Conclusions...

[baka_boy]

Java3D is actually based on OpenGL. Yes, that means that there is C code running at a low level (i.e., the OpenGL implementation provided by each graphics card provider), but that is no different that *any* language other than C that uses the OpenGL standard, including C++.

I agree that Java may have missed the mark, as far as performance-intensive applications like games are concerned, but given that people are seriously interested in Python-based game development (as evidenced by pygame, PyOpenGL, etc.), I think it's hardly reasonable to attack it on the basis of performance.

Personally, I'd rather hear the opinion of someone who had actually worked on commercial-scale gaming projects. For those of you who have actually worked in the field, what features were present (or missing) from your choice of implementation languages and platforms that would have improved your productivity, or the quality or performance of the finished game?

Re:Conclusions...

[mvw]

Java3D is actually based on OpenGL.

No, for Windows you can either choose a version using Direct X or one using OpenGL for rendering.

Yes, that means that there is C code running at a low level (i.e., the OpenGL implementation provided by each graphics card provider), but that is no different that *any* language other than C that uses the OpenGL standard, including C++.

My complaint is that there is no Java3D version that is portable and free at the same time. But that is my general problem with Sun's Java licensing.

I agree that Java may have missed the mark, as far as performance-intensive applications like games are concerned, but given that people are seriously interested in Python-based game development (as evidenced by pygame, PyOpenGL, etc.), I think it's hardly reasonable to attack it on the basis of performance.

The present Java games are not bad. But they are the same league, like games written in Flash are. Hard to imagine a Java title would show up in the games top 10, and this mainly due to the fact, that most top titles try to really use the hardware at its limits, thus performance is an issue.

Personally, I'd rather hear the opinion of someone who had actually worked on commercial- scale gaming projects.

Java gaming is a good resource. Several of my colleagues are former game professionals. They watch the Java game development community with great interest. As far as I can tell, their opinion on Java for gaming seems to range from promising to not suitable (at least not for Quake III like games, where state of the art 3d engines are needed that squeeze out every cycle).

The crucial question for them is if you can make money with such a title, which seems to be not easy in the games industry. Perhaps it will be in the mobile phone market?

No question, really. But not soon.

[Snowfox]

I make games for Midway Games. Here's my perspective as a console developer...

In my mind, there's really no question about whether Java itself is useful, or whether it could clean up the development process. It is, and it could. I don't doubt that in the near future, we'll see a game system for which most games are written in Java.

The current limitations are these...

First, using a language like Java, despite all that you hear and believe, demands additional processor time and additional space. Only one or two current game systems are up to the task at present. You won't see a change until all current-production systems are up to the task, because virtually every game development house is leaving the option of a universal port open, if they're not already targeting all three major systems. Nobody likes closing their options.

Second, because game systems have typically been very restrictive in terms of RAM size and CPU power, most game developers are accustomed to working at a very low level. They're used to cycle-tuning. They want complete control over the system. Getting most to even consider C++, let alone something as far removed as Java, is an uphill battle. There's a lot of cultural baggage ("this is the way we've always done things") to shed, as well as a lot of relearning to be done. Eventually, it will probably be imperative that Java or some universal event-driven scripting toolkit is adopted. But for as long as possible, the majority of the individual established game developers - the ones who are usually in charge of complete production teams - will avoid making any fundamental changes to their tools.

Next - we work with the tools we're given. Not a one of Microsoft, Sony nor Nintendo have been pushing Java. Accordingly - most of us haven't even evaluated the possibility. The concept is far enough removed that we still joke about whether being a Java programmer is an oxymoron.

Lastly - who wants to be first? Somebody's going to have to take the plunge. Until someone who's - due to personal preference or financial incentive - just gonzo java-crazy jumps in and makes a well-performing Java-based hit, where's the guarantee that going Java is even safe? It's good in theory... but so was WinCE-based Saturn development, and you saw how many hits came from that approach. (Hint: They all have WinCE startup screens, so you'd know if you ever even saw one.)

Re:No question, really. But not soon.

[Joe Rumsey]

There was an article about someone wanting to write a multiplayer game engine in C# not long ago. I posted something very similar then. I have yet to talk to anyone who has actually made games professionally and has seriously considered using Java. But a lot of people, many of whom are experienced programmers outside the gaming industry, who haven't seem to think it's a good idea, it comes up all the time.

Skimming the paper in question, the author even says that Java development is not recommended for consoles, and in fact using it is not even possible in most cases. Furthermore, he wisely realizes that it may never be possible for the X-box. His final conclusion is that because of the lack of console availability and due to performance considerations, Java is only feasible for low profile games or high profile but low performance games, and of course only for PC-only games.

As you say, somebody would have to take the plunge first. But I can't imagine who it would be. The problem is it's going to be very hard to convince an experienced developer like you or me to try it for a long time to come, and inexperienced developers have a big enough learning curve to get over without also trying to blaze a trail in a new language.

Unlike you, I do doubt that we'll a system that uses Java as it's primary environment any time soon. It won't happen on the current generation of consoles, and I highly doubt it will happen on the next. Beyond that, it no longer fits my definition of the near future. It's too many product cycles down the road to make any reasonable predictions about what people will be using. I do think we'll probably see Java being supported in the next generation (PS3, GameHypercube, Y-box, whatever), but not widely used.

Re:No question, really. But not soon.

[Craig Maloney]

I thought the WinCE stuff didn't come into play until the Dreamcast. And, much to my biased chagrin, there were a few WinCE titles, most notably the Sega Smash Pack series. Part of the Saturn's downfall was that it was too difficult to program with it's various chipsets and such.

Re:No question, really. But not soon.

[Craig Maloney]

That's understandable. Saturn really was an underrated little system that should have been bigger than it was. :)

Re:No question, really. But not soon.

[armb]

> I have yet to talk to anyone who has actually made games professionally and has seriously considered using Java.

nGame. Not consoles (or PCs), but they do use a Java based system.

http://www.ngame.com/corporate/technology.html
http://industry.java.sun.com/javanews/stories/stor y2/0,1072,37890,00.html
http://www.wirelessgaming review.com/articles/ngame 072701.php

A few holes, with a bonus link on optimization

[Xenophon Fenderson,]

I have several criticisms of the report.

1. For each language, the report conflates the standard library with the language itself. Languages are grammar and semantics. Many specifications also describe aspects of the language run-time environment, but this is not part of the language proper.
2. The paper makes little distinction among lanaguage/library implementations. This means that comparisons between Java and C++, especially when comparing performance, are not necessarily comparing apples to apples. Hand-waving implementational differences, especially between two different programming languages, is sloppy at best, especially when one may see vast differences in "performance" within a family of language implementations, e.g. in the Common Lisp world, the CLISP implementation (which compiles Lisp to byte codes running on a C-based VM) is said to have good bignum performance, but the CMUCL implementation (which compiles Lisp to assembly codes) is said to have superior fixnum and floating point performance.

Ok, so with all this talk of performance, there is this really neat paper called "Optimization: Your Worst Enemy". It has an eye-catching title but it's really worth a read.

Re:A few holes, with a bonus link on optimization

[joto]

I failed to see more than one criticism, as #1 and #2 looked very similar to me.

The idea that you can somehow separate language and run-time environment is of course partly true, but for most people not very realistic.

Case in point: the standard C library. Most of the stuff here (with the exception of the varargs mechanism) is not part of the C language. Yet very few people would even consider using something entirely different, even though many (of the most used) parts of the standard C library really sucks (e.g. stdio is slow, malloc/free is more unreliable and slower than region-based memory management, there are plenty of functions that are not reentrant, etc...)

Similarly, few people would develop java programs without at least the support of the classes in java.lang.*, java.util.*, java.io.*, java.net.*, java.awt.*, javax.swing.*, and so on. While it is possible (and probably easier than in the C case), most people just won't do it, for much the same reason as they wouldn't do it in C.

And the reason for that is simple. You loose portability, you loose common knowledge, you end up with libraries less debugged and less trustworthy than the well-tried counterparts, you do a lot of unecessary work that could be better spent at your application, etc...

Now, if this was a comparison of what was the "best language" (without qualification), then I would consider your critiscism appropriate. But it wasn't. This was a small survey to see whether it would be useful to write a game in java. And that meant using standard off-the-shelf compilers and libraries. If you wanted to implement your own run-time libraries, you could just as well implement your own language.

As mentioned above, this wasn't a comparison of java vs. C++. It was a comparison of the run-time speed of MSVC++ 6.0SP5 versus Intel C++ 5.0 versus JDK 1.4.0 server versus JDK 1.4.0 client versus Excelsior JET Professional 2.1 versus IBM JDK 1.3.0, with an eye towards game-programming, and taking into account factors such as readability of the tweaked (optimized) code, developer time, portability and robustness of the different platforms. Considering that, it would be quite stupid to not take run-time libraries into account.

Re:A few holes, with a bonus link on optimization

[mvw]

For each language, the report conflates the standard library with the language itself. Languages are grammar and semantics.

Java the language is not too interesting (just a dumbed down C++ version, or sanitized C++ version depending on who you ask :)

Of course one is comparing the Java 2 SDK (the language, the libs, the compiler, the hot spot vm, plus the available IDEs) to the Windows/MSVC++ combo.

Hasn't Lisp already proven this?

[Jayson]

Since there have been games written mostly in Lisp already, doesn't this empirical proof extend to Java or other higher-level languages? I have seen comments such as "nobody wants to be first" and that there is "cultural baggage," but wouldn't Lisp's trail blazing really have been these new firsts and unloaded some of the cultural baggage?

Re:Hasn't Lisp already proven this?

[DGolden]

Well, Lisp has a reputation for use in AI programming, so games programmers often think of it when considering scripting languages for enemy control - e.g. Abuse. (though, of course, there's nothing magic about Lisp that will make your enemies behave more intelligently, a dumb loop in lisp is still a dumb loop.)

Java has a reputation as a rather pedestrian C++ variant (though due to its dynamic features, javais actually more like a cut down smalltalk with C++-like syntax), and really is a pretty boring and ordinary language. "21st Century COBOL" is how it's been treated in the corporate environment.

Re:Hasn't Lisp already proven this?

[dstone]

there's nothing magic about Lisp that will make your enemies behave more intelligently, a dumb loop in lisp is still a dumb loop

LOL. A loop? If you find yourself writing a loop in Lisp, well... maybe it's time to stick to imperative languages until you've seen the functional light.

Re:Hasn't Lisp already proven this?

[DGolden]

Almost true, but much truer of Scheme than Common Lisp.

Common Lisp is emphatically not a purely functional language, its proponents will tell you it's "multiparadigm", and it's not all that unusual to see explicit loop constructs and other imperative stuff in production code. Sometimes the imperative form really is the more natural way to express something.

CL really gives you the best of most worlds in programming.

Scheme isn't purely functional either, but does tend to steer you toward functional programming more than CL, but largely through dropping stuff than Common Lisp programmers tend to find useful...

mobile phones

[jilles]

Java gaming is going to happen, just not on the PC for the moment. Right now, mobile phones are being shipped that have a JVM on board. It will be a matter of time before someone figures out how to use that for games. The same applies to PDAs.

These kind of platforms require the kind of safety and security Java offers. Particularly being unable to corrupt manually is a very nice feature since you typically don't reboot your phone.

As for 3D gaming on the PC there's some stuff to consider. You have game engines, game code that uses these engines, standalone games and low level APIs such as directX or opengl. If you look at the quake and unreal engines (responsible for most of the succesful 3d games of the past four years) you will find that they include their own scripting languages in which most of the game functionality is implemented.

In addition both John Carmack (quake) and Tim Sweeny (unreal) have considered using Java for that job in the past (way before stuff like hotspot compilers was around). For various reasons they chose not to. I recall Tim Sweeny saying in an interview he needed a more domain specific language than Java to script the objects in the game. Performance was not so much a concern (after all they ended up using a scriptlanguage).

I don't believe we're going to see much Java games in the next few years. The existing game engines are simply to good and to mature to compete with. However do foresee a shift from the low level details of rendering 3D stuff, doing 3D sound, etc. to game functionality. Already many games just use third party engines for their games. Developing your own engine only makes sense nowadays if you're able to sell it to others. One engine for one game just isn't economically feasible anymore. Likely the game engines will continue to be written in C/C++. However its just a matter of time before there will be gameengines that can also expose their API to Java or .Net. Thus allowing gamedevelopers to use a higher level, less error prone language than C for the game functionality.

Re:mobile phones

[armb]

> Right now, mobile phones are being shipped that have a JVM on board. It will be a matter of time before someone figures out how to use that for games.

It's already being done. See my reply http://slashdot.org/comments.pl?sid=29201&cid=3141 877

Embedded game languages (e.g. Unreal engine)

[smcv]

Scripting languages embedded in C or C++ game engines, like Unrealscript in Epic's Unreal series, seem to provide a good compromise - many of the advantages of Java, but without the performance problems. (but then, I make Unreal Tournament mods, so perhaps I'm biased...)

Epic Games' Unrealscript reference has some background on this. Some of the interesting bits:

Why they didn't use Java:

During the early development of UnrealScript, several major different programming paradigms were explored and discarded before arriving at the current incarnation. First, I researched using the Sun and Microsoft Java VM's for Windows as the basis of Unreal's scripting language. It turned out that Java offered no programming benefits over C/C++ in the Unreal context, added frustraging restrictions due to the lack of needed language features (such as operator overloading), and turned out to be unfathomably slow due to both the overhead of the VM task switch and the inefficiencies of the Java garbage collector in the case of a large object graph. Second, I based an early implementation of UnrealScript on a Visual Basic variant, which worked fine, but was less friendly to programmers accustomed to C/C++. The final decision to base UnrealScript on a C++/Java variant was based on the desire to map game-specific concepts onto the language definition itself, and the need for speed and familiarity. This turned out to be a good decision, as it has greatly simplified many aspects of the Unreal codebase.

Game content and even third-party mods designed for Windows work perfectly on the Linux and MacOS ports of UT:

UnrealScript is bytecode based: UnrealScript code is compiled into a series of bytecodes similar to p-code or the Java bytecodes. This makes UnrealScript platform-neutral; this porting the client and server components of Unreal to other platforms, i.e. the Macintosh or Unix, is straightforward, and all versions can interoperate easily by executing the same scripts.

Why performance isn't always vital (my emphasis):

UnrealScript is a slow language compared to C/C++. A typical C++ program runs at about 50 million base language instructions per second, while UnrealScript runs at about 2.5 million - a 20X performance hit. The programming philosophy behind all of our own script writing is this: Write scripts that are almost always idle. In other words, use UnrealScript only to handle the "interesting" events that you want to customize, not the rote tasks, like basic movement, which Unreal's physics code can handle for you. For example, when writing a projectile script, you typically write a HitWall(), Bounce(), and Touch() function describing what to do when key events happen. Thus 95% of the time, your projectile script isn't executing any code, and is just waiting for the physics code to notify it of an event. This is inherently very efficient. In our typical level, even though UnrealScript is comparably much slower than C++, UnrealScript execution time averages 5-10% of CPU time.

Re:ATTN: Some "Research" ahead.

[Anonymous Brave Guy]

They make the BIG mistake of comparing two languages -again- and choosing a favorite.

And as usual, many of the points made in favour of one or other betray a lack of understanding that disqualifies them from having an informed opinion anyway. It's sad but true that most critics have never taken the time to understand that which they criticise.

Java for games?

[rufusdufus]

How easy is it in java to control the floating point settings of the FPU such as rounding and accuracy? 3D physics simulation is very sensitive to these settings.

How can I write a game which is compatible with 3D glasses standards?

Can I access 3D hardware functionality? Hardware lighting or multipass texturing?

How much control do I have over the garbage collector? I don't want weird pauses happening at the wrong times.

Can a java program change the screen resolution and color depth?

How much control do I have over sound mixing? Can I use 3D sound?

Re:Java for games?

[jacobmarner]

When asking a question: "Can I do X in Java?" and X is something that requires access to some piece of hardware the answer is always that it is possible via JNI if not via the Java standard library. You should not feel limited by the Java standard libraries - if there is something you miss it is easily wrapped an accessed via JNI in a few minutes. If you can access it from C++, you can access it from Java. So for the specific questions: >> How easy is it in java to control the floating point settings of the FPU such as rounding and accuracy? 3D physics simulation is very sensitive to these settings. I don't know. >> How can I write a game which is compatible with 3D glasses standards? Already part of Java3D. Can be done via JNI. >> Can I access 3D hardware functionality? Hardware lighting or multipass texturing? Yes. >> How much control do I have over the garbage collector? I don't want weird pauses happening at the wrong times. Read the report page 37-38. >> Can a java program change the screen resolution and color depth? Yes - possibly only via JNI. My own game at www.rolemaker.dk does this. >> How much control do I have over sound mixing? Can I use 3D sound? All you want. Also via JNI. Wrapping a C++ for use in Java can be done in a few minutes so it is not something that should be considered a limitation.

Native compilation

[harmonica]

You don't have to use the interpretation approach of the JVM. There are native compilers for Java, and they are used especially with embedded systems where you cannot allow interpretation overhead. Some native compilers allow you to turn off cycle-eating things like array bounds checking etc.

The report PDF mentions them briefly on page 18, but adds that there are some "portability problems in practice". I'm not quite sure what that is supposed to mean - if there are errors in the executables generated by native compilers, it's a problem of that particular tool, not of the native executable approach in general.

Re:my experiences with java gaming

[mvw]

There is no such thing as a "dll hell". All .dll's are loaded from your current working directory, your path, and the windows system directory, in that order.

Of course there is.

What do you do if some application already sucked in version 1 of a dll, while another application needs (the incompatible) version 2 of that dll?

Even using Java doesn't prevent from dll hell under Windows. I experienced exact this problem with the (native) Java driver of an OODB. :(

Another obstacle is controlling the load paths, which is not always possible.

For this, the .net "assemblies" will hopefully turn out to be major improvment.

Regards,
Marc

Re:my experiences with java gaming

[mvw]

Thanks for the link. It tells about the lookup procedure for dlls. So much so good.

It is a bit unclear in regard to the term The directory from which the application loaded. In my case we talk about a set of Java jar files, moved over to the client box via Java Web Start. The application running is the javaw.exe in some installation directory. Over several stations it will pull in the jar that contains the reference to the native code which will trigger the LoadLibrary call. It could be that this LoadLibrary call is in some file different from the javaw.exe position.

However my particular problem was a different one: It was not about not finding a dll but instead some other program already pulled in an older version of the dll now I'm busted.

The kick is that it is a different program only from the perspective of the Java programmer and user (here a database inspector written in Java, there a Java Web Start application), but it is the same program from the perspective of Windows (the same javaw.exe that interprets both Java apps).

To be more precise: somebody already opened a database inspector tool, this is a java program too, but it will trigger a LoadLibrary call to an older dll revision. Thus we have javaw.exe mapping in old.dll. Now I need to ran a Java program that needs to use new.dll, which would make the same javaw.exe to map to new.dll.

As far as I understand, I can't do this, because it is the same app for windows.

A solution would be to have a dedicated Java VM (with its own javaw.exe) that is used for Java Web Start execution. I used a different solution in that I created a Java based installer that does some detection work and pulls in an application part that references the same foo.dll hat was already pulled in, if.

Is this DLL hell? I would say yes.

Regards,
Marc

Re:my experiences with java gaming

[mvw]

This is why I in my report recommend that you bundle your own JVM with your app. That way you can put any of your DLLs in the same directory as your javaw.exe, you are sure it is only started with your app, and you are sure that the JVM behaves exactly as during your own tests.

Yes, that sounds like the right thing to do.

In fact the Java installer for use with Web Start I created to pull in matching DLLs was based on sample code by a poster from the JWS forum over at Sun, who first published how to roll your own JVM for Web Start installation. :)

Different JVM has different performance characteristics and take different non-standard parameters, so you can play safe only by bundling your own JVM.

I thought about this shortly, when 1.4 came out recently which triggered a couple of errors in our large application (one we had was a funny error regarding the Vector class, another remarkable one the fragility of 1.4's jpeg decoder which dies on jpegs with embedded thumbnail preview :) But I would probably (out of lazyness) just twiddle with the part of the jnlp descriptor, where one mentions the allowed JVMs, if I hadn't had this discussion with you guys. Hm, probably the most fruitful discussion I personally had on Slashdot for a long time. Something wrong here? :)

BTW, I have heard several people complain that they couldn't get the Java webstart to work (as users), so I don't consider it stable enough for production use.

No doubt, Java Web Start is not a ripe product. I grapple with it for several months now, and experienced many pitfalls with it. (Read the jnlp/JWS developer forum over at Sun for more :) It is frustrating to see such a good idea only finished for 90% or so.

I was surprised that Sun put it in 1.4, regarding the quirks which are not ironed out yet. On the other hand this will force them to repair it sooner or later.

Perhaps they had to simply issue it, regarding that .net assemblies and the global assembly cache look very similiar like JWS, if I'm reading their descriptions correctly.

From what I saw, Java Web Start was developed initially on the Solaris Plattform, and then ported to Windows in a hurry, without thinking too much if it was really possible to recreate the same under Windwows.

I believe this because some parts of the JNLP API (I mean the support services which should be offered by any JNLP client) like triggering a jar/resource transport into the JWS cache, or removing an item from the JWS cache do not seem to work properly under Windows. At least I didn't get them to work. The reason for their failure might be that files that are in use can be deleted under UNIX without problems, while they can't under Windows.

Further, the main two technical guys (Rene Schmidt who wrote the jnlp Specification, and another guy who seemed to do the implementation) seem to have vanished from Earth. They showed up on the jnlp discussion forum up to a certain point in time (about may 2001) also the last Java One article by these persons showed up around that time. Then nothing. Looks to me like they were taken away from this project, with the result of no major development happening anymore to the product (except small bug fixes).

Other madness includes dealing with native libs, where surprisingly Windows caused me less pain than Linux. I still don't know if a certain problem I had with Java3D distribution via JWS (which was possible for Windows), which involved having to resolve circular shared library dependencies, is really fixable or a principle problem.

Then we have the fact that Java Web Start is program useful for client boxes, and these are in 90% of the cases Windows machines. In certain for my company commercially interesting company environments, such boxes are administered well, which means that the user has no Administrator priviledges, in contrast to the typical home user.

Everything, including JWS installation, and the voodoo the Java app deployed via JWS might need, can't depend on having adimin rights there.

Unfortunateley the driver of the OODB we used, required admin rights for it's installation. (Which was unnecessary for a pure client setup - they required it because their install also included the case of server install, which would have added a Windows Service/daemon).

Others detected JWS dialing out to Sun, which should be a big no in a secured company environment.

Just a couple of items which showed a lack of real world usage of JWS. :)

Then we have the JWS cache update mechanism, which is often unpredictable to me. And a bloody "lazy/eager evaluation" behaviour and strange dependency tracking and ..

BUT, when JWS works, this is a damned comfortable and useful thing. It helped us much during inhouse development, when the non developers had to test things. People who don't know the intricacies of Java installation on their boxes and how make Java apps run from jars. They just want to click and launch.

Thanks again for discussing with me, I hope the insights won will help me to make our app more bulletproof!

Regards,
Marc

Re:my experiences with java gaming

[mvw]

As far as I can see all your problems stem from the fact that you are using the javaw.exe to run your (non-managed) app as opposed to using some native code and running a native app.

Before the discussion with you guys here, I blamed the mess just on Windows. I thought once an instance of a dll is mapped into some process, no other process can map the same lib (same means, same interface signatures, the name of the dll is slightly different) but of different (incompatible) version successfully into its process memory space. I realized that is not true, because I don't have two different processes. I mistook the two different programs (db inspector, our JWS app) for different apps. But they are not. Both times the same Java interpreter (javaw.exe) is active. Which means one shared instance in the code segments and probably some kind of shared management of mapped in dlls, as an exe under Windows is really just a mapped in kind of dll, if I remember right. This is very likely the reason for my dll trouble.

If I use two different Java interpreters, eg by installing a second runtime (or better like it wa s suggested above, if I deploy the JWS app with its own Java interpreter). Then I have really two different/distinguished apps in memory, which should have not interference when loading the dlls.

About switching to native code: Too bad I have to use Java, and the available JWS version, even if it has bugs and undesirable behaviour. :)

While I have sources for them (this stuff is available under Sun Community License) I am not allowed to fix matters and distribute an "improved" version of the JRE and JWS to our clients. :(

That license issue is my personal problem with Java. I understand that it helped Sun to fight Microsoft for a certain degree, but for me this is a hinderance.

Sorry about the disgression from the original game topic of this discussion forum.

Re:my experiences with java gaming

[mvw]

As the Database Inspector allready had his LIBRARY.dll loaded the system refused to laod a second library with the same name. Instead of that the system linked the allready loaded library to the Java program.

We observed link errors with our app if someone used the db inspector tool before.

What I didn't realize before was, that this is not the same like running two different apps like a.exe and b.exe.

In fact this is java.exe interpreting a.class here and the same java.exe (in a different instance, which typically just means a different data segment for a new set of instance variables) interpreting b.class there.

Now a.class has a System.loadLibrary() call that pulls in old.dll while b.class has a call that pulls in new.dll. Thus Windows must map somehow old.dll into the javaw.exe process memory plus must map new.dll at the same to into javaw.exe process space. This won't work with just one (shared) javaw.exe code segement instance in memory, I guess.

I will try it tomorrow. :)

Re:my experiences with java gaming

[mvw]

If a DLL is allready loaded there will no second one get loaded, the already loaded one is reused(so the one in the dircectory where the AP is is IGNORED!).

You describe the case a.exe loads a.dll and b.exe loads a.dll (same name, but this a.dll containing incompatible code).

Which won't work, because we end up with both a.exe and b.exe mapping in/sharing the first a.dll only.

Java however gives you with custome class loaders full control over your loaded classes. No problem to have the same class in endless different versions in your VM :-)

Funny enough this seems to turn out a kind of Java specific problem:

We have two different Java apps, which means at some point two different Java classes, that explicitly contain a reference each to a natively implemented OODB driver.

The thinking mistake was that these are not two different Windows apps. It is just one, the Java interpreter, interpreting two different Java apps.

Re:Java ? Maybe one day.

[mvw]

Computers are not really taken advantage of nowadays.

Well the Apple ][ people did amazing things with their weak hardware. But that was when hardware remained the same for a longer period. Today you can observe the same with the game consoles, which also show some impressive usage.

Weak compilers,

My impression was that compilers got cleverer, and need to get cleverer for the 64 bit PCs.

Java will be a viable choice when the bytecode is run directly by commodity cpu-s.

The interesting and unique bit about Java bytecode is not it being just intermediate code, but it being security proven intermediate code.

Actually a computer architecture would be interesting, that "thinks" in classes, objects and references.

Something like the old Lisp machines did?

Re:I'm very curious

[mvw]

I've never done official tests, but Java always seems to take an order of magnitude more memory, and runs much slower.

Memory waste seems to be a bigger problem in Java, then it is in C++. (Which in turn has a much worse performance impact than the usual suspect VM interpretation).

I am not exactly sure why this is.

• Is it because people have a garbage collector and thus they get more careless about memory cleanup?
• Or is it because Java programs are on a higher abstraction level than C++ programs (which means more complex object hierarchies with much unfortunate temporary object creation/destruction)?

Maybe someone can explain to me, how Java could be faster than C++.

One argument is that a JVM like Hot Spot does dynamic compilation. The typical C/C++ code gets one once compiled. The resulting exe is hardly optimized after, even if you might take it to quite different execution environments.

Code generation involves making assumptions about the execution environement and will result in certain influential decisions.

A JVM like Hotspot however probes the present environment and will profile how the compiled code behaves, and will probably try improving matters during interpretation.

This might lead to better and thus faster code than the static one, we are used too.

I believe Intel's C/C++ compiler does a dynamic optimization at runtime too.

Might be interesting to compare that one to Hotspot Java code. :)