Hi!
I'll start with a warning - my post will be rather long, may sound noobish and contain some questions that have been already asked, so if you have no time nor patience, don't read it 
So, let's start from the beginning.
I'm about to choose a game/graphics engine. As I don't want to waste my time, I try to foresee as many problems as possible.
I'm seriously interested in jME, that's why I collected all my doubts and I'm going to ask you about those, that I couldn't answer by myself.
Here is the list of them:
1. Learning jME
Learning the very basics of jME doesn't seem to be hard. You can collect some pieces of information from tutorials or user's guide.
But when it comes to advanced features, I feel helpless. Most chapters in user guide are not written, tutorials are not numerous, javadocs seem empty…
How shall I find out, what is the meaning of field Texture.ACS_TEXTURE or understand the role of WaterRenderPass class ?
Is searching forum and endless question asking the only solution ? Can you convince me, that learning jME will be nice and quick?
2. Isn't the use of Java language a big disadventage?
Java is probably still much slower than c++ (I don't know how much - if somebody could find a link to reliable comparison, I'll be grateful). Is writing 3d games in Java a "dead-end" or "at least" inefficient nowadays? Should I be afraid, that my games will have to be much simpler and smaller to work fine and even then there will be always the possibility, that "gc" will start working during most crucial part of the game?
Well, in fact these are the most important of my doubts. Please, consider them as questions, not accusations… In fact I admire you and the effects of your work, but I simple want to find the best solution for myself.I would be grateful for your help.
I'd say, look in the User Showcase what some users have created. A lot of these did this in very little time, and with never having used jME before. Maybe some of them will post here.
As for documentation, there is a Test for practically every functionality (which you could see as a mini tutorial). There is some functionality that might require you to look at some OpenGL documentation. Certainly knowledge of OpenGL would help, but it's not required when you start. What's important is a solid knowledge of Java.
As for C++ vs. Java, this has been flamewarred to death on the internets… and since you're dealing with people here that build or work with a Java based 3D engine (and some are using it on a proffesional basis) so the answer you get here will be very predicatable. (Search this forum using Google for C++ if you like). To summerize, ever since Java 1.2 Java code is (or more correctly: can be) compiled when you run it using the standard Sun VM, so there's no reason whatsoever for Java to "still [be] much slower".
llama is correct but I'll add a few things because I think kamykadze is right on some things as well.
Yes, there are tests for pretty much everything but just because a test uses 'Texture.ACS_TEXTURE' in it without any comments or explanation whatsoever, I still don't really know what 'Texture.ACS_TEXTURE' is/means/does. I can change that value and re-run the code to see what breaks/changes but even then I only gain a cursory and external understanding of it.
I equate it to being able to drive a car or being able to assemble a car. Running the tests or nabbing some code from them and using it in my game is like driving a car. I don't really know how everything in may car works, but I know if I push the gas pedal, it goes forward. I can pretty much learn to drive a car by just observing other people doing it. Assembling a car would likely require a manual I could refer to. I could watch someone assemble a transmission, but I'd be unlikely to repeat that feat myself after watching it a few times. This requires more than just mimicking the process, I need to understand HOW the gears connect and work together. If I don't, I may not be able to tell if I have successfully assembled all the parts. I can simply throw it together and determine it's not right at the end, but then I wouldn't know where to begin troubleshooting.
I think the knowledge level people are seeking for jME is somewhere in-between being a 'driver' and a certified mechanic, it's something more like the guy who can change his own oil, swap spark plugs, and replace brake rotors but who won't be welding together his own custom made exhaust system any time soon.
I've found that that is a difficult level to reach as it requires more work along the 'certified mechanic' route than it should. What I mean by that is all the source for jME is there, anyone can sit down and take the time to read it and if you are fairly competent with Java and go buy an OpenGL book you'll come out of it with MUCH more knowledge. But that's like going to class and studying for your certification test. It's a lot of work. Programmers by and large are a lazy bunch - we write programs to do work FOR us. So asking for that kind of investment from all of your prospective users is likely a bit much. There's no good middle ground. This isn't a secret to anyone, people continually ask for improved JavaDocs, or more fully fleshed out examples that go beyond just code and include an explanation OF that code.
All that being said there are people working hard to provide that - Landei and others. And to be honest, kamykadze, you asked if you should go to the forums for help - the answer is yes. We are very lucky to have an incredibly helpful community here. There is no elitist attitude from the devs or other jME experts here towards noobs. They still expect you to do some work but most will answer any reasonable question quickly and with appropriate detail.
As for Java vs. C++ - at the current time they are often very comparable in speed, so much so that you should probably focus more on ease of use and community support than raw performance. I think there's still a lot of remnants of the original gripes against Java floating around. Java 1.6 is quite good and, in general, Java continues to get better, faster, and more capable with each release. How much community and development effort is raging around C++ these days?
Sorry for the novel all.
i think the major reason that plp still writing games in C++ is coz the C++ game engines have been around for so long. basically all of the commercial engines r written in C or C++. and this forces plp who work on games to use C or C++.
personally i think java just got better in the gaming field after 1.4. and thats not a very long time for plp to actully switch from the old engines to the new ones. especially the old ones r still capable of handling the game graphics now days. so there is no reason for plp to start writing new java based game engines since they already have alot working and familiar C++ ones. java is not slower than C++, true. but its not faster than C++. even though it takes less time to write an engine in java, but u dont gain anything after all. and u still have to spent the time writing the new engine. on the other hand, most companies do have one or a few C++ engines that r already working. so y spend the extra time to produce something that u already have?
to sum up, the reason y companies dont use java for games is not because java is not as good as C++, its simply because java is just as good as C++, but not a whole lot better. so if u r considering making a game with jME, java vs. C++ should be ur last concern.
Ok, you have convinced me, that there are major reasons for professionals to keep programming in C++.
But what about the amateurs and newbies? Do they simply follow the game programming guru's and don't try to make the best decision by themselves?
There is NO major reason for game engines to be written in C++, for that matter there are papers on internet explaining why using C++ for game engines is a bad thing. C++ allows lots of mistakes to be made, which lead to hard to find bugs. If you look around how much C++ game engines suffer from memory leaks, it becomes a synonym. The power of C++ is in its fast access to the video bus, which is important factor, but not the most important. I think i read somewhere that Java beat C++ in numerical computation. So, without actually testing this, i guess you will push textures to video card faster with C++, but you will have faster physics calculation in Java.
If you take that John Carmack knows what he says, then stick with OpenGL. Everyone jumped on the DirectX bandwagon, except the biggest game engine programmer ever. It means something.
vear said:
If you take that John Carmack knows what he says, then stick with OpenGL. Everyone jumped on the DirectX bandwagon, except the biggest game engine programmer ever. It means something.
I expect MS will eventually give him a big enough wad of cash to change his mind...
And so he can spend it all in Armadillo Aerospace, since I think he's tired of customizing Ferraris.
Carmack's latest engine "tech4" (used in Quake Wars ET) is still OpenGL, and the next one "tech5" is also OpenGL based at least (it was shown on a Mac). Of course both these engines also have ports using Direct X style tech (XBox 360).
That OpenGL is independent of Microsoft is not just important from a "politcal" point of view. Carmack has very close connections with both nVidia and Ati, and has a lot of direct influence on the OpenGL driver development.
Just my 2 cents here, since so much have been said already and by so many talented people:
Java is only slower typically on the first couple of seconds of running the critical code (i.e. the one that will be ran for minutes, hours or days like the MMORPG game loop :D). After that, the JustInTime TM compiler will take over and optimize the code with very aggressive techniques (all of which you might already know). So… I leave you with some benchmarks I saw on the web:
http://www.kano.net/javabench/ <-- Notice the Java 1.4.x and is now comparable speed to C++.
http://www.artima.com/articles/io_design_patterns3.html <-- I/O system comparison again with 1.4.x
http://www.javaworld.com/javaworld/jw-02-1998/jw-02-jperf.html <-- Very old, but interesting.
http://www.dmh2000.com/cjpr/index.shtml <-- No benchmark as much as an article discussing the issue about many languages.
Notice that coding style and programming techniques are what, in the end, will decide the speed of your application. Also, if you don’t have an army of experienced programmers, you might want to code in whatever is simpler.
what i miss most is easy use of all nice middleware out there(free and commercial)…
MrCoder said:
what i miss most is easy use of all nice middleware out there(free and commercial)...
At the risk of taking this offtopic - what middleware specifically?
just from the top of my head…pathengine, lightsprint, cgfx runtime, geomerics enlighten, speedtree, natural motion euphoria/morpheme, havok, silverlining, spirops, pixelux DMM, ProFX, Fork particle, RakNet…
and lots more free ones that arent that big/complete but still useful…also helplibs for math, imageprocessing etc…
kamykadze said:
The prejudice can't be the reason, as Java is much nicer and easier language.
Yes.
I have had a lot of experiences where many C and C++ programmers simply consider Java a language good only for Web Apps.
In the past I tryed to recruit, developers for a jME based project, asking in some IRC chats of developers. The weird thing was that in several Java developers (not only C or C++) channels they started to make a fool of me. Because they was skeptical about jME and they treated me as like as a poor mad.
One of the developpers, I have been able to recruit, was still skeptical after he accepted to join me. Other developers who accepted to join the team (awared thet the project was based on jME), after some days, started to discuss and argue about the possibility of using a C or C++ based engine, like Irrlicht, Crystal Space or Ogre.
At the end, the project never begun, and I closed it. In this experience I discovered also the reason of this developers behavior. Most of them are basically ignorant!!!
I can make you a simple example. In that few days, we discussed about differences between C/C++ and Java. In particular we discussed about variables passed as value or as reference. Every good Java developer knows well this difference. They are C/C++ developers but they do not know it well.
Try to start a discussion about it in a random development channel (C, C++ or Java) and see if everyone say the same thing.
in c++, you can use ultra secret turbo fast special sse4 commands. in java, you can't.
Yes you can! Java HotSpot VM should do it for you by compiling the critical (most used) pieces of code with maximum optimization for the currently used hardware (CPU). If they are not using sse4 yet, they surely will in future release of Java VM. Which is yet another nice thing about java: all you have to do is update the virtual machine and that in turn speeds up all your code. You never have to recompile anything. And you get all the optimizations at zero-cost in your development time.
Java, Java community and Java acceptance are still growing and growing rapidly. LWJGL and JOGL are fairly recent developments than enable Java to be used with 3d games. Before these technologies were out it was not possible to use java for a fully-blown 3d game (Java3d just didn't have enough features). So the reason most people are not using Java for 3d games is because 3d capable Java is still a very new technology. Projects like jME are helping this technology to mature. When it's mature enough (like C++ is for 3d games), then Java will gain more acceptance and more people will start switching to Java.
So the only question you should ask yourself when choosing jME is:
whether you want to follow the pack (then stick with C++ like everyone else does)
or you want to lead the pack (then jump in and help Java establish itself on the 3d market).
Heh, thought I might add some as well 
HamsterofDeath said:
a compiler cannot replace a bubble sort with a quicksort.
But you can, whether you are using java, c++, ada, python... doesn't matter!
HamsterofDeath said:
no vm can eliminate object creation in loops and allocate the object's members used inside the loop on the stack outside the loop and recycle them. i can.
Actually I think they can, dunno how it works though. But current jvms are said to be faster using short-lived objects anyway, so they basically eliminated the need for that optimization, and made a shortcoming become a feature!
I'm in. And I have to say: It's been like a crusade, but we'll finally get there someday.
no you can't, at least not directly. there was a rfe suggesting native methods to access these commands because the jit won't be able to do the same optimization as a programmer could. the rfe was closed.
JIT is what was used in older JVM, the newer ones (im not sure about 1.4, but 1.5 and up) are HotSpot VMs which do things very differently. Here is a paper from sun describing HotSpot VM: http://java.sun.com/products/hotspot/whitepaper.html#3
There is alot of research going on to improve JavaVM, so if they are not fully using sse4 yet, they surely will eventually. And the argument that compilers are worse at optimizing code than programmers is a very very old one and has been proven wrong every step of the way.
i meant hotspot. which is a jit. i think. doesn't matter. what i meant is: the hotspot vm has to guess what i am trying to achieve, but i KNOW what i want.
lets say i randomly access array elements. in a loop, the hotspot vm will understand that i begin at 0 and end at length-1, so it can eliminate the bounds check because an arrayindexoutofbounds cannot happen. if i access random elements, the vm must do the bounds check because it does not know if all the indices i use are inside the bounds. it cannot optimize everything better, because it has less information about what i'm doing.
i know the compiler/vm is able to do optimizations beyond anything the programmer can do, but this is limited to low level stuff. a compiler cannot replace a bubble sort with a quicksort. no vm can eliminate object creation in loops and allocate the object's members used inside the loop on the stack outside the loop and recycle them. i can.
Actually I think they can, dunno how it works though.
i heard rumors about 1.6 being able to do escape analysis to achieve this (it is significantly faster than 1.5), but doing the optimization manually still is several times faster