contact.htm is a example of a simple animation controled by a java applet in a multi user world
rotAnimationApplet.html is the same animation in a single user world
rotAnimationVRML.wrl is the same animation controled by vrmlscript in a single user world
downlaod all the files including the java source file

blaxxun's Applet API Packages
blaxxun Contact 3D EAI
tecfa's section on java EAI much of my initial info on using java EAI in contact came from here
 

I first tried Java in blaxxun contact towards the end of May 2000. At the time I had not tried much javascripting or vrmlscripting but thought java was the obvious choice for animations. I had a lot of hope for java thinking it would allow me to have close to the same speed and the same flexibility to what I was accustomed to getting from c++. I assumed java would be a lot faster than vrmlscript because vrmlscript has to go through an interpreter unlike java that can execute code compiled into native code due to it's "just in time"(JIT) compiler. About a month later after a lot of passionate intensive work trying to make Java work free of problems I came to a dramatic conclusion that java had to many problems to be worth bothering with. I had ironed out a number of bugs that were there due to my ignorance but there still seemed to be problems where the applet would not work for everyone. If this was because not everyone had java enabled then this alone was a real problem. I was getting really tired from asking visitors if they could see my green land that was all generated by my applet. I never met any one from the blaxxun community who could help me. I felt quite alone with a number of problems all java related.

The worst problem was when java was used in Netscape I noticed disk space would be eaten up slowly. It would take a while if you had plenty of disk space but if left long enough your computer would crash when all the free disk space was gone. You could regain all your disk space if you refreshed your browser or left the world with the java applet in it before you crashed but I just did not like this sort of thing. Having all that disk drive activity must have made my animation more jerky as a result.

If I did not use java for animations which I now suspect the EAI may not be intended for I would not have had those Netscape disk eating problem but It hardly seems worth the bother of having the added complexity of including another language that's so limited in use and a language that does not come free of other problems.

I found that IE would always say it was trying to download a file and visitors would ask why, I never knew if it was meant to be like this or not. Netscape did not do this.

I can't be sure of this but I thought my animations under java control were not as smooth as the same animations under the control of vrmlscript.

Java was slower to develop than vrml script in that I had to compile my files first and then open a new browser because just refreshing would not load the new compiled code, however since then loanewolffe has told me all you have to do is press control while u click on refresh so that problem is solved now. Only compile time now is all that should make it slower but that does not bother me so much because I have found if you use the right compiler such as the microsoft compiler it compiles pretty much in an instant.

Vectors in the Java EAI can only be treated like arrays of floats that is if you have a vector variable called "vec" you can not do some thing like vec.y = 5; like I am use to doing in vrml script and c++ instead you must write it as vec[1]=5; which I don't like much as it makes code more error prone.

Java is much less likely anyone is going to bother copying your techniques but this also makes Java have the disadvantage of making code less open to the public so reduces the chance of any one from learning any thing from it.

Java's syntax is more strict than vrmlscript which is good for reducing bugs that arise later on if programs get big and ugly but the reality is switching to vrmlscript has proven to be a good decision for me so far. After I converted my hoppy code to vrmlscript I was keen to see just how slow vrmlscript was and what it was capable of so I tried 5 hoppies using just vrmlscript. I was very pleased to find all 5 of them on my then small techuelife island on my 300 Hz K6 2 CPU were very very smooth.

I keep finding new possibilities with vrmlscript and have come to realise it's much more flexible than I had once imagined it to be. I thought my hoppies animation code would be very taxing for vrmlscript because they use lots of trigonometry functions. Thinking about this more though I conclude that slow functions like sine cosine or square root functions should not be the concern I at first thought they would be because they end up being calculated by a single machine code instruction at the same clock speed what ever the language they are executed from. It's when you get into slow loops with lots of instructions is when an interpreter can run into problems concerning speed. A JIT compiler should make initialising tasks much faster like generating land forms but the main thing I wanted speed for was for my animations.

If any one can tell me I have some thing wrong here or if you know of any solutions to the problems I had or if you have actually tried using java in a blaxxun multi user world with or even with out animations please let me know. My conclusions remain the same and for over a year now this page has remained unanswered by anyone!