What is the "cleanest" way of determining what version of the Java runtime is used ? I would like to force users to use Java 1.4 (for javax.nio for example) and I was wondering if I should just try and instanciate the javax.* in question or getting a property like java.vm.version or java.tuntime.version. Is there another way ? Which one is the most common ? And do you think it is better to impose future users a Java version or to have a game engine just like the G4FJ having only interfaces and different implementations for specific versions ? For me it''s another lack of time but it will be worse if I have to think of it when it''s already finished and all is done a monolithic way. What do you do (or plan to do) for your own java game dev ? Herve.

Depends on your angle. If you are just trying to determin if a specific set of libraries are avalible, just try and instanciate one of them. If you are really shooting for the whole package nio, fullscreen, .... then using the system property might be a better way to go.

BTW: nio direct byte buffers have a bug that make them terribly slow. It was filed as a bug, but because it didn''t crash the VM sun let the performace problem slide and will not fix it. The diffrence between normal heap accesses and byte buffers was ~20x worse.

Looks like I''m going to require 1.4 too for the Java2d performace/fullscreen support.

I saw some posts regarding ByteBuffer performance problems on javagaming.org forums but, it seemed to me like a duel between someone from (or close to) Sun and a user so I didn''t really notice. Could someone explain briefly what is the problem ?

snowmoon, you say it won''t be fixed. But then what is the point of using nio in this case ? I need a console (Quake-like) in my game and I was thinking of ByteBuffer for it as I am using GF4J and ByteStrings. So I am gonna be back to byte arrays if people at sun don''t fix it.



By the way, don''t know if javanerd will read this post but I was wondering if the current version of GF4J uses nio for its ByteString class in the JDK1.4 engine. If so, it would be that there is a way to actually gain speed with nio.



Herve.

Silencer...

To sum it up. Java.nio''s ByteBuffer stuff still doesn''t quite work right. There is a way to workaround the problem though. Currently you can cast the return object from allocatedirect to a mappedbytebufffer and regain 90% of the speed loss.

This is a poor fix, because the API could change the signature of the return type at any time so that casting it to mappedbytebuffer will not work anymore, or they could fix it so that we don''t have to screw with the return type. Their is also another permenent fix, but that requires going in and changing java.nio class files.