I guess my main concern is this. I have a choice, I can use java and Jogl, where I have no problem with compatibility with my component and that of others in my team, or I can use C++ and have problems with compatibility.
Depends on what compatibility concerns you have. Java/JOGL isn't going to solve any hardware compatibility issues that you have. So if you have compatibility issue with hardware, JOGL still isn't going to be a solution for you. If however you're talking about portability - sure, your JOGL application once built will be immediately portable to any platform for which the native libraries have been compiled and has a JDK1.4+ JVM.
However, once I start with Jogl I can't after 2 months just say, no it's not yet suited for commerical use, and I guess it won't be so I'll go back to plan A. I need to be sure that JOGL won't give me too many problems. This is especially a concern with compatibility with other video cards, especially with things like shaders and extensions.
If you can't take any risks, I would go with technologies that have existed for more than a few months. But that's just me. There are absolutely no guarantees that 6 months down the line you won't come across something that either Java, OpenGL, JOGL, etc can't resolve.
Another question, but still related, is it not possible, with JNI to feed data from a java applet to native C++ code running it's own openGL implementation.
So writing the rendering part, windows window creation etc.... in C, but having a java program executing it directly? That may be another way to go.
Sure. That's what JOGL does. If you're really serious about wanting to minimize your risks, I'd strongly suggest you actually look at the source to JOGL and build some proof of concepts.