[java] How important is Platform Independence?

Since you posted anonymously, I can insult you ... you are insane. 99.99% of gamers use Windows? Where do you get that figure? Do all of the users of MAC OS, BeOS, Linux, Unix, etc not count? I will admit that over 90% of all computer users have "access" to a Windows OS, but that does not mean they prefer to be forced to use it ... and in the case of MAC or console gamers, they cannot. I have worked programming Windows DirectX 6, and I liked it. Now I am employed programming for BeOS, and I like that too ... but I can tell you at our company (which creates consoles for movie post production) half of our employees don''t have a Windows OS installed, so they don''t get to join our afternoon Unreal Tournament break ... how much better it would be for them if they could ... and even for the rest of us, we mostly have to boot to Windows just for the game ... which is silly.

Anyway ... if your writing platform specific, runtime critical code (like blazing fast game engines) why would you want to use java? Game engines are typically written using a subset of C++ (meaning just like C programs, only organized into class libraries, with some use of interfaces and virtual functions).

I wish that we were at the point were platform independence was feasable, but that is not yet the case with cutting edge games. Computers are more than fast enough to handle an ftp client that is only 1/3 as efficient as it could be, but if the performance on Quake3 had to take even a 20% loss in the rendering code, it would become nearly unplayable on relatively powerful machines (machines without $200+ graphic accelerators can still only handle about 800x600 resolution with high detail).

Just look at the needs of your program ... if it''ll run on a Pentium 233 with 4MB graphic accelerator (say S3 virge) in 32 MB RAM ... then you can afford platform independence ... otherwise .. you will probably need platform specific code or libraries - so accept the inevitable and do what you gotta do.

OK, I have long opinion in this topic so here goes...

First, I think that full platforms independance is utopia for games. It could be cool, to be able to write your problem once and it would then run on both game consoles, on PCs and Linux. However, systems such as consoles have a widely different set of input/output devices than PC so in reality making such a full platform independance if utopia - it is good for net based operation where the environment is the same but for games, I think not. Users expect programs to be written specifically for their system - as a PC user I hate being forced to use a game pad... (And a side note to the first ano poster - console games represent the majority of the global sales within gaming so if you count consoles and Linux it is more likely you are down to about 50% using WIndows (I don''t have the exact figures). Oh and java *does* exist to the Sony playstation...)

The best we can hope for is to write so code that with a minimum of effort can be ported to other platforms for use there. Given this it means that we should try to isolate all platform dependent things in as few modules as possible to make it easy to port. Doing this in Java is easier than with say C++ because so much effort has been put into platform independance.

Given that platform dependance is present anyway, it is my argument that then we might as well use platform dependant libraries to speed things up - *if* we can isolate their use to a few modules. And if possible use of such libraries should be miimized elsewhere as it may cause more work when porting.

So in conclusion I think we should use platform dependant libraries in a controlled way.

Although Sun are making libraries such as JMF available and classify their use as pure Java, then this isn''t making the system platform dependant. All those optional packages (including pacakages such as Java3D) are not really platform dependant due to the fact that they have only been made available on a few platforms. The result is that for pure platform independance you are stuck with JDK 1.1 without using any extra libraries you can download from Sun - and with that package there is pretty strict limits to what is possible to do.

As some of you know I have written several platform dependent libraries myself for Windows. One that allows you to program native Windows applications (called JWindows) and one that allows the use of the Quake II-like engine 6DX from Eldermage (it is called 6DX for Java). So I am in strong favor of platform dependant libraries - without them no proper commercial non-applet games will ever see the light of day.

Jacob Marner

felonius wrote:

quote:

---

The best we can hope for is to write so code that with a minimum of effort can be ported to other platforms for use there. Given this it means that we should try to isolate all platform dependent things in as few modules as possible to make it easy to port. Doing this in Java is easier than with say C++ because so much effort has been put into platform independance.

---

I really have to disagree with the statement that Java is easier to port to other platforms than say C++. Given the context of this discussion I can assume that you mean porting Java games is easier than porting C++ games. Unfortunately that would be an incorrect statement. While Java is a powerful, viable language, it does not have as wide acceptance or the flexibility that C++ has when used to develop games . In order to achieve maximum performance in Java, it is often necessary to use unportable libraries or, worse yet, unportable implementations of Java ( Microsoft''s Visual J++ anyone? )

The key to developing any portable application is to separate interface from implementation. The key programming patterns used to facilitate this are "Bridge", "Abstract Factory", "Prototype", and "Proxy" - just to name a few. By utilizing these patterns effectively the main engine of a game can be developed in pure C++ (no compiler extensions etc) and can be linked to interface classes. The implementations of the interface classes are provided in separate libraries, specifically optimized for a given platform.

Any how, my wife is nagging me to get going for dinner. So I''ll close this off ...

Don''t take this the wrong way, I''m not attacking Java - I''m just pointing out that it is a common misconception that Java is truly "Write once, run anywhere".

Dire Wolf
direwolf@digitalfiends.com

quote:

---

Original post by Dire.Wolf
I really have to disagree with the statement that Java is easier to port to other platforms than say C++. Given the context of this discussion I can assume that you mean porting Java games is easier than porting C++ games. Unfortunately that would be an incorrect statement. While Java is a powerful, viable language, it does not have as wide acceptance or the flexibility that C++ has when used to develop games . In order to achieve maximum performance in Java, it is often necessary to use unportable libraries or, worse yet, unportable implementations of Java ( Microsoft''s Visual J++ anyone? )

The key to developing any portable application is to separate interface from implementation. The key programming patterns used to facilitate this are "Bridge", "Abstract Factory", "Prototype", and "Proxy" - just to name a few. By utilizing these patterns effectively the main engine of a game can be developed in pure C++ (no compiler extensions etc) and can be linked to interface classes. The implementations of the interface classes are provided in separate libraries, specifically optimized for a given platform.

---

Hi Dire.Wolf,

I respect your argument and agree fully that when making portable code (for any language) seperating implementation and interface is very important. It is true, (and I myself has argued that) that writing games for Java needs unportable native libraries. But so do C++ games - they also use unportable libraries.

But my point is, that assuming that you use isolate all these unportable libraries behind a portable interface then it would be easier to port a Java version faster than a C++ version. This has not something to do with the libraries used (which in both cases must be completely rewritten for the new platform) but the portability of the language constrcuts themselves, for instance:
* No matter the platform the various primitive types are identical in java. This is not the case in C++.
* C/C++ compilers have many differences across platforms - java compilers don''t. Just look at many of the GNU sources you have with Linux and you will see that the code is springled with preprocessor defines to take care of variation between UNIX platforms. For a "portable" C/C++ developer it is a nightmare to stay compatible with all this compiler variations. This is much easier in Java.

But admitted, the language is not as important an issue here as the implementation/interface seperation - and with regard to this issue the advantage of Java over C++ might be deemed insignificant by some.

One point where C++ has the advantage here is that most unportable libraries today are available for C++, not Java. This means that adapting a unportable library to your engine on the new platform is less of a hassle with C++ than with Java.

In the end, I think we agree, but my point just needed a little clarification. Do we agree?

Jacob Marner

Oh, one thing I forgot. Dire.Wolf, you mention Microsoft J++ as an example of an unportable Java compiler. True,

However, this compiler does not confirm to the standard and is thereby by definition not a Java compiler. In other words, Microsoft has made some strange compiler for a java-like language but it is not Java (why do you think Sun is sueing Microsoft and making them change their implementation).

If we just stay clear of these non-working clones, then all is fine.

Firtunately these non-wroking clone compilers are rare and almost all compilers are standard conforming. With C++, it is different - actually I don''t know of any current Windows based compiler that is fully conforming on all issues as described in Stroustrup''s 3rd Edition. There might be one for UNIX, but gcc is certainly not standard conforming.

Note to all: Microsoft J++ is to be avoided!!!! I use Windows and Microsoft C++ a love both, but Microsoft J++ is a piece of junk that should never have existed. Over and out.

Jacob Marner

Actually, i''d like to say something about portable libraries. Being both a Java and a Linux developer, i know a little about this stuff. Writing a C or C++ game that is portable is not much more work than writing any game as long as you set out with portibility in mind. Generally, the installer and QA type stuff are the only things that require a seperate effort for each platform.

SDL (http://www.libsdl.org) is a good example of a library for C that allows platform independent development. ClanLib (http://www.clanlib.org) is another example of a platform independent library, this one for the more object oriented bunch. Of these two i suggest SDL, myself, though it doesn''t really fit in perfectly with the object oriented paradigm. Still, it would make perfect sense to me for someone to make a Java port of it, and i''m sure you''d be well recieved. There have been ports to MANY other languages already.

Technically, you''d still have platform dependent Java, but it''d be much better than just DirectX support. SDL supports Windows, Linux, MacOS <10, MacOSX, FreeBSD, BeOS, and possibly Solaris and IRIX, though i''m not sure about those two.

-ben.c

Jerry got the ball rolling, now let me continue.

Platform independence is a nice bonus to me and I have my library that I can use to access the platform dependant features transparently. And I agree with Shelrem, you can achieve platform indepency also via C/C++ if you use the appropriate library. The most important thing for me in Java (when compared to C/C++) is the less hairy syntax and the lesser errors/line ratio I get when writing code. I''m a hobbyist game writer and call me funny, but on my free time I don''t like to tackle any more difficulties with the programming than I have to. I just want to get an idea, plan a couple of pretty diagrams on paper and be done with it on the implementation side. Of course I enjoy taking up a challenge every now and then, but that is purely voluntary.

I don''t think Sun''s concentration on OS portability is that much of a hindrance for game writing in pure Java. The hindrance comes from their focus on "serious" application development. Most of the Java library components have been written to accommodate all sorts of different application requirements, but not too many of them are suitable for game development. E.g. sound support has been and for the most part still is an achilles heel.

The announcement of VolatileBitmaps (bitmaps that are stored in video memory and that can be drawn with HW acceleration) in JDK 1.4 is good news for us, but this again raises the (IMHO) true culprit of Java: Cross JDK compatibility.

The deprecation mechanism is a better way to remove old functionality instead of just chopping old features from the library immediately in newer versions. But it doesn''t remove the problem that the library is still changing. And by now we have quite a variety of JDK''s 1.0, 1.1, 1.2, 1.3 and soon 1.4. It used to be enough to write your game in 1.1 and it would work practically in all of the JVM''s, but when JDK 1.4 arrives it will most likely be in some ways incompatible with 1.1. And this incompatibility will be difficult to handle as it might come up even in the simplest of tasks like when trying to save the Properties object (save() in pre JDK 1.2 vs. store() in post JDK 1.2). Not to mention the sound support fiasco: first in JDK 1.1 you had only the unofficial "hacked" sound support, but it allowed quite easily you to write support for any audio format you liked and even do some streaming. Then in JDK 1.2 they "removed" the hack and offered the "official" way of loading only WAV and MIDI files. Then in JDK 1.3 they introduced a completely new way of handling sound. And how many games have you seen that don''t use sound? Not that many I guess.

This problem becomes even more difficult to handle if you are trying to write Applets as there has been rumours about Microsoft removing Java support altogether from the next IE version. Say what you like about Microsoft''s take on Java, but at least it offered decent multimedia API''s in the form of DirectX without the need to get your hands dirty with C/C++ (of course it is debatable which is the dirtiest C/C++ or COM/ActiveX).

What do you think? Is cross JDK compatibility a real problem or am I just seeing things?

I just want to state that using Visual J++ doesn''t have to mean platform dependance


''''2+2=5 for extremely large values of 2.''''

I have to agree with Fovster, just using Visual J++ does not mean
platform dependence on windows.. As long as you do not use any
of the microsoft specfic libraries it will be still be pure java.

War doesn''t determine who is right, war determines who is left.