I've been aware of the problem with programming for different Java versions for quite a long time (I've followed Java from its first 1.0 alpha releases)... But just recently it hit me that I'm writing a game programming library that is supposed to allow you to program for different Java versions. That means that I should propably somehow offer a unified class library for all these different libraries, right? And after that came the obvious realization that one could actually make better (faster & less memory consuming) implementations of many of the default Java library classes. E.g. one article in Gamasutra website ponders around this subject: Dirty Java - Optimizing Pure Java. And lot of the statements made there are true: multithreading under Java games is overkill due to expensive synchronization, Unicode strings are huge and slower to process than the simple ASCII ones. So how about it, anyone interested in participating in this endeavour? We could make this library a separate package from my GameFrame library just to make it usable to larger audience, but I'd like to keep it open source so that anyone can go ahead and integrate it to their game or customize the thing to their hearts content... This project would go where no-one has ever gone and it would offer great opportunity to familiarize yourself with the dark side of Java programming: optimization. Which actually should happen before any code has been written I've got a few links (besides the one above) to sites offering Java optimization tips and tricks. I'll post them here if we get a big enough group behind this. Edited by - javanerd on 2/16/00 12:48:33 PM

Oops, I forgot to put the closing /A tag in the link above and the link got screwed... Here is the link again (hopefully this time it''ll work):

http://www.gamasutra.com/features/19990618/dirty_java_01.htm

Maybe, but I''d be more interested in doing data structures, plus the fact that Sun already did an STL-like package...I don''t know. Can you be more specific? (Sorry, haven''t visited your website or downloaded GameFrame ).

I''ll have to disagree with much of what was in that article, yes unicode is going to be a bit more cpu intensive to process, but the overhead in threads is far outweighed by the performance boost they give you. And there are unsynchronized data structures in java, you just have to use something besides Vector.

As for rewriting java source... not for me.

Unicode strings are huge and slower to process than the simple ASCII ones.

I read somewhere that *they* will make dual ASCII/Unicode, but hell, i''m not sure if it was somewhere on "JavaMegaSpeedBoosterMCXIV the most reguested implementation to Java" web pages, there is many of them, too ;-)

Hell, I always forget my name ;-()

Unicode is not the real problem with Java strings. On most modern architectures, dealing with 16 bit characters instead of 8 bit characters is not going to break the bank.

The problem with Java strings is that they are immutable objects - every modification done to a Java String object causes a new instance of a String object to be created.

so for example the following line
String a = "one" + "two" + "three" + "four";

involves the creation of 7 string instances:
"one", "two", "three", "four", "onetwo", "onetwothree", "onetwothreefour"

But Sun has a solution in the JDK - the StringBuffer class. If you are doing heavy string manipulation, you should use the StringBuffer to store intermediate results. It''s syntax is not as convenient but it performs better.

The overhead of threads is more of a platform-specific and VM-specific kind of thing. There are different implementations (green/user and native), and each platform has its own overhead for thread creation.

Generally, the overhead of synchronization also depends on the VM''s implementation. Clever implementation of monitors can make the overhead of the noncontested case as little as one instruction.




-vince

I can see the justification for writing replacement classes if one was doing so as part of the development for some proprietary engine. Say for example, if you were going to use a Java based engine for several commercial products within a particular game development company.

But if your target is to provide an open source game development tool for the masses I think you would want to stick to the standard Java technology as much as possible.

Your game toolkit will probably need to be flexible to allow developers to integrate it with other Java technologies, such as sound API’s, Java 3D, Java 2D, Input Device related API’s… Attempting to ensure compatibility between your replacement classes and the large number of other Java class sets would be a major undertaking. With a proprietary engine you would know exactly what technologies you need to support to build your products. With a toolkit aimed at a mass distribution you risk making the toolkit unusable to a lot of developers if you place limits on which Java class sets you can integrate with.

Your replacements may have compatibility problems as soon as the JDK was upgraded. You might be putting yourself in the situation of trying to keep the replacement classes compatible with the most recent releases and java extensions. This wouldn''t leave a lot of your time for the development of game related functions.

Just my humble opinion.

If you''re going to do it, I would suggest finding a site that is devoted to custom java implementations and post about it there. I''m not saying don''t post it here, I''m saying that it might help keep you motivated. Something like www.gnu.org or jfa.javalobby.com

quote: Original post by joeG

Maybe, but I''d be more interested in doing data structures, plus the fact that Sun already did an STL-like package...I don''t know. Can you be more specific? (Sorry, haven''t visited your website or downloaded GameFrame ).

"STL-like package"? Are you referring to the collections framework that is included with Java 2 or is there another package thingie I haven''t heard about?

Datastructures are a good starting point. I had in mind some of the classes in java.util and java.lang packages that are essential to game programmers, but have been changed between JDK 1.1 and 1.2.