> Let me know what you think. > Don't hold back ... I didn't
On the contrary I appreciate your honest opinion.
Initially I was thinking about Java3D myself. Some time ago I played a bit with it.
I certainly am not an expert on 3D stuff. To be honest I didn’t find it particularly easy to work with but I think the reason for this was I didn’t find a good “introduction to Java3D programming” on the net.
Secondly I had the impression that the development is not exactly a priority for Sun so I was not sure if it was such a good idea to use it for our project. I thought also that it might be hard to find programmers with some experience in Java3D.
> I think that Java losing mindshare and going "out of fashion" is a more > legitimate concern.
What do you mean by this exactly? Are there any *signs* to support this?
I had the impression that Java is a settled *thing* in business application development.
Are there any alternatives at the moment? Surely not C#?
>>I have noticed a considerable improvement in speed compared to 1.4.
> It is good to hear that you think it is faster. Sun PR said that it was > faster. The specific graphics operations I want are still too slow. (I > said that the graphics operations are slow, not that Java is inherently > slow.)
I didn’t do any benchmarking on it but the software I am working on showed a considerably improvement on start-up time which actually was a pleasant surprise.
> Now, for my random thoughts. In fact, my blunt advice:
I will give you some more points to consider first.
1. The molecular modelling stuff will be done in stages. There are different levels of modelling possible. Ab-initio is the best but also the most CPU intensive. In fact you need a supercomputer or a cluster of very big computers to handle at most 100 atoms or so but in the end you are sure you know just about anything there is to know about your molecule. There are other approaches to do modelling based on semi-empirical and empirical algorithms, which are (a lot) less, accurate but can handle from thousands until millions of atoms depending on the algorithm.
We would like to incorporate some of the less CPU intensive algorithms in our CAMD tool. VASP (or another) would be used separate from our tool and is, as you said, for a multiprocessor environment. That is why I mentioned that the CAMD tool needs to be able to show the result of the simulation. That, but only that!
In fact we would prefer that anybody with a reasonable recent computer (2+ GHz) is able to use our CAMD tool. The same holds for the DC client.
2. [EMAIL PROTECTED] (the first Distributed Computing (DC) project) has been developing a general purpose DC environment called BOINC. It is meant as a platform for all DC projects. People will be able to switch between projects without the need to load another DC screensaver. They will also be able to participate at several DC projects at the same time. The software is written in C++.
Although it is not used anywhere at the moment ([EMAIL PROTECTED] will start with the distribution for their project soon) most people in our project want to use it. I am almost the only one who is opposing it. Some are doubting but tend to agree with the majority.
I am opposing it because I think most make the mistake in thinking that “Joe average” is interested in participating in more than one DC project. I do not think this is the case. No doubt there *are* people that are interested in being able to switch but those are not the *average* kind of people.
I think that *betting on one horse* is not the right way to proceed. There are other projects interested in BOINC but they already have their own DC environment so for them it is only an additional path to other spare CPU cycles. (You can use both environments in parallel on the server side). I haven't heard about a new DC project that *only* wants to use BOINC (except ours that is).
3. From the start I was sure we had to add native libraries if we wanted to use Java. (It is time consuming to develop molecular modelling software even the ones using empirical algorithms). But I thought it would not pose a problem using the JNI package. Do you have any experience with this?
Actually I do not understand why most DC projects do *not* use Java. To me it seems the most logical choice as Java (Sun) is mainly focused on business application (database access and stuff) and I am sure Java is optimised for this kind of applications.
> I believe that C++ has an advantage over Java in the area of OpenGL > support, but you are not currently thinking of using OpenGL.
Actually I have been thinking about it. One of the reasons I thought about Java3D in the first place.
Am I incorrect in thinking that Java3D uses OpenGL?
> I am not a fan of Java3D ... as a broad market product. Nevertheless it > does work (I assume) and it does have its place. And I think its place is > for applications like yours. Java3D will slowly gain broader support and > acceptance over the coming years.
Why didn’t you use it for Jmol? Was it a personal thing maybe?
Why do you think it *has* a future at all? Sun doesn’t seem to promote it very much and they don’t seem to work on it (not much anyway). I have been thinking about contacting the Java3D developers team about it but I haven’t yet. Maybe I should!
Regards,
Valère
------------------------------------------------------- This SF.net email sponsored by: Enterprise Linux Forum Conference & Expo The Event For Linux Datacenter Solutions & Strategies in The Enterprise Linux in the Boardroom; in the Front Office; & in the Server Room http://www.enterpriselinuxforum.com _______________________________________________ Jmol-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/jmol-developers
