Hello again, just wondering if Xith3D will make some changes since 1.5 beta released with load of new features, like in the Group class changing from an ArrayList of objects to an ArrayList of Group’s/Nodes and all of thous constants, into logically grouped enum would be quite cool and great step ahead of java3d
:-/ Im not sure it is a good idea to “hurry” the jump to jdk 1.5 . This last is far to be stable enough for the moment.
As soon as 1.5 will become stable, we definitely will be using new language features, new high-perf timer, etc. But before 1.5 will reach at least RC status, we will preserve compatibility with 1.4.2.
As of enums, there is a discussion about this in JOGL forum. I personally see static imports much more important than enums (for now), but we will see.
It would be great to use new language constructs, like foreach loops etc. to make Xith3D code cleaner, but it has no performance advantage, so it is not so big deal.
I see more important step - a convenience package for scenegraph creation and manipulation, but this is not 1.5-dependent.
Yuri
I think the new hi-res timer is a good reason to jump to 1.5.
Concerning cleaner code I think a lot of other things are very important (code conventions, guidelines for exception/error handling, documentation of the structure of Xith3D and most important a better Javadoc). Maybe some “cleanup” can be done when we switch to Java 1.5 compatibility.
IMHO two things would be quite useful - generics, so it would be clear what kinds of collections/iterators are returned from various methods and covariant return (cloneNodeComponent is best example).
I would be vary of foreach, because it creates Iterator even for ArrayList. This is not a problem in B2B app, but in realtime graphics it is always another piece of garbage.
Enums - certainly not for opengl (there is a reason why they have not been done such way in C), but for scenegraph, they could be useful - no more wondering which parameter goes first into PolygonAttributes (polygon mode, cullface comes second 
Static import - can be useful for rendering part, where there is a need to import opengl constants.
Annotations - useless for this project I’m afraid.
Autoboxing - ugh…
I would personally wait at least until Eclipse will get support for all new language features. Other people will probably want to wait for vi…
I am all for using Java1.5 of course - but there is one draw back.
Java1.4.x has a fairly good amount of penetration at the moment and it’s a shame to waste it. For example the new sony laptop my boss pruchased came with, yes you guessed it, Java 1.4.2 pre installed.
Shame as it is dumping 1.4.2 support - there is many many compelling reasons to move up, not least of all Java Web Start improvements. I agree with the sentiments about waiting for at least an RC however.
Will.
100% agree with abies. Lets wait for RC and then will decide.
Yuri
Indeed- and it could be some time until MacOSX see’s Java1.5 - but hay u never no. maybe get Xith3d to Version 1.0 first?
oh and i see Apples VM now has a good Timer! huray… should we implement that back in now? or can u set it somewhere in Xith3d so it uses a timer u pass it?
[quote]Indeed- and it could be some time until MacOSX see’s Java1.5
[/quote]
Yes I think a 1.0 release on 1.4.2 would be great, then move on to 1.5 with the post 1.0 development.
Mac OS is caught up in terms of released JREs - now having 1.4.2. But ONLY on OS X 10.3 (Panther). The 1.5 release is likely to lag behind Sun’s by a few months at least I would guess. It would be great if Mac had a release Xith3D to use while waiting for a 1.5 JRE.
I mentioned this on another subject line, If we move to a newer java release then xith3d needs the ability, internally, to tell a user that their java version and xith3d are incompatible. This will reduce error/problem posts by a large percentage. How many people have been told in these forums that their opengl version is out of date, a LARGE BANNER to System.out would have reduced these posts. An internal ValidateXith3DAgaqinstThisSystem class would cleary announce
“The java release jdk1.4.2 is incompatible with xith3d 1.2.3.4, please install the 1.0 version of xith3d or upgrade your jdk.”
[quote]Indeed- and it could be some time until MacOSX see’s Java1.5 - but hay u never no. maybe get Xith3d to Version 1.0 first?
oh and i see Apples VM now has a good Timer! huray… should we implement that back in now? or can u set it somewhere in Xith3d so it uses a timer u pass it?
[/quote]
Yes you should use the high perf timer for OSX, however Thread.sleep() on OSX is surprisingly high resolution as well.
I thought that Java1.5 was byte compatible with previous versions of Java (e.g. 1.4.2) so if you changed the code to include all these nice 1.5 features, as long as you compile with -target=1.4 your class files will still be work on Java1.4.2 systems.
It just means that if you want to compile Xith3d yourself you need Java1.5 installed.
I also noticed that with static imports the compiler doesn’t look up the class hierarchy, so in my case I use LWJGL and must statically include the CoreGL11 and CoreGL14 classes rather than just using the GL class which extends these, rather fustrating to say the least.
Andy.
[quote]I thought that Java1.5 was byte compatible with previous versions of Java (e.g. 1.4.2) so if you changed the code to include all these nice 1.5 features, as long as you compile with -target=1.4 your class files will still be work on Java1.4.2 systems.
[/quote]
Nope. If you use -source 1.5, the compiler requires you to use -target 1.5. There are a lot of changes in 1.5, for example, synthetic attributes became synthetic access specifiers, ‘+’ characters became valid in identifiers, the LDC/LDC_W JVM instructions now support CONSTANT_Class constants - which means that class literals are compiled down in a totally different fashion, etc…
Now that I’m done explaining that, I can perfectly segue into introducing my new free, open-source project - Retroweaver. It’s a tool that transforms class files compiled by JDK 1.5 into JDK 1.4 compatible class files. So, you can use JDK 1.5 features like generics, autoboxing/unboxing, static imports, etc… but deploy to a 1.4 VM.
Xith3D, for example, could be written and compiled in 1.5, but remain binary compatible with 1.4.
Give it a shot - http://retroweaver.sf.net.
God bless,
-Toby Reyelts
That sounds very smart!
Even OpenSource.
wow that is a good tool!
If it works as you say it does, then any reasons for hanging onto 1.4 for xith3d vanish.
woohoo!
Will.
ap_kelly - the GL classes are now final and no longer extend each other, so that trick won’t work with the new LWJGL anyway. There are sound reasons for the API change.
Cas 
[quote]wow that is a good tool!
If it works as you say it does, then any reasons for hanging onto 1.4 for xith3d vanish.
woohoo!.
[/quote]
Only one way to find out.
God bless,
-Toby Reyelts