Develop Reference

Approach to use for animating a 2D game like Tower Defence on iOS/android

If I am going to make a game like Tower Defence on iOS or Android, do I need to use OpenGL ES extensively? Or am I merely using textures without using other features like geometry transformation, lightning, drawing primitive shape and such?
Secondly, if I am only using the sprite-sheet to animate the game, could I stick to the native platform provided library without the use of OpenGL ES? For example on iOS, using the UIImageView class animation method to perform an animation.

This is such a complex question that you will hardly receive a conclusive answer.
In short: There is no need to touch OpenGL at all to do a game.
Every method that you describe would work, but with various advantages and disadvantages. A short excurse for inbuilt frameworks on Android:
Use standard views (like FrameLayouts): The Framework can do most of your work (animation, z-sorting, ...) but you will run frequently into weird layout errors and surprising performance hits. This is because you are essentially perusing a UI framework for a game. However, for a very simple game it might be just the right thing to do.
Use Canvas painting: Android contains a good and rather fast 2D graphics library in that. You can use it for games, it will deliver enough performance for many games. However, you have to do more yourself already (e.g., z-sorting, animation) and some high-end effects are still not possible
OpenGL ES: Best performance, most choices. Good luck, when starting from scratch, there is A LOT to do before you get even the simplest stuff on the screen. On the other hand, you can do things that are almost impossible with the other approaches. Also, it's possible to reuse parts of the code for multiple platforms.
Renderscript: In my experience even worse than working directly with OpenGL in that the learning curve is even steeper.
In short, design the game first, then decide on which framework provides enough functionality for that without being too complex.
And finally: Think about not doing all the plumbing yourself but take a look at the existing game engines (Unity for example). Almost anything you ever need will be in there; furthermore, some of these engines work even cross-plattform: Write your game once, publish it on iOS AND Android!

3D Simulations in Java

I have never done any 3D programming and will be working on a 3D aircraft crash simulation. I am going to do it in Java, though I know C++ is probably more popular for this sort of thing, but I have no experience with it and a limited time frame.
Could anyone recommend any engines or wrappers? I know there is Java3D, but isn't it getting a bit old now? I have also seen JMonkey Engine, although that is for games I am sure it would be fine for simulation software?
Thanks!

You're going to have to firm up your fidelity requirements before you're going to get a truly useful answer to this. Some observations:
Java 3D - It doesn't appear to have had much active development since 2008 (though it looks like it's been ported to use JOGL). If it does what you need, go ahead and use it, but don't expect it to get any new features anytime soon (unless you want to write them yourself). Since it's mainly a scene graph manager, it may be of use for display, but it doesn't have any physics simulation capabilities.
JOGL - This is the OpenGL bindings for Java. Its most recent stable version is also about 4 years old, but there are indications it's undergoing some development to take advantage of newer OpenGL features.
jBullet - This is a physics engine for gaming purposes. It's essentially a Java port of the C++ Bullet Physics engine.
jMonkey - This is a gaming engine, which combines both a rendering engine (Java 3D) and a physics engine (jBullet) into a single package.
Back to my main point. If your requirements can be satisfied with a game engine, then you're okay to go with something like jMonkey or if you want to strip it down, just use JOGL and jBullet.
The downside is that most physics engines used for gaming don't deal with aerodynamics so much as collision detection and constrained movement. There appear to be a few flight simulator extensions for jBullet, but I can't make any recommendations about their quality... I suspect they too are for gaming purposes.
If you want to start dealing with structural failure simulation for the purpose of engineering analysis and the like, you might be able to get these tools to do the rendering and at least a small part the physics associated with it. But a physics engine tuned for gaming is not well suited to this kind of analysis. For that you will need a professional engineering package, or a professional engineer with a background in aeronautics, mechanical engineering, modeling and simulation... and who knows how to program in Java.
As for
what happens to other aircrafts in the airspace, actions taken by
aircraft controllers and the debris field.
Most of this is not going to be included in any physics engine, even one suitable for engineering analysis. There's some aeronautics and mechanical engineering involved, but that only constrains what's possible. What you're talking about deals with human behavior under stressful situations. That's a focus of much research, but you're unlikely to find anything available either as open source or commercial software to satisfy that part of your project.
Bottom line, get a better understanding of your requirements. If you don't have that understanding up front, you're going to be solving the wrong problem.

Other alternatives are:
lwjgl (website) A gaming library including GL binding and support for controls and sound .
ode4j (website) A 3D game physics library. This is a Java port of the ODE C/C++ physics library.

Is Processing (2d graphics) appropriate for larger projects?

I'm going to be working on a decent-sized game in clojure and for now it will have 2d graphics. Is Processing (or rather, Quil, which is just a clojure wrapper for Processing) an appropriate tool to use for this.
Processing presents itself as a way to quickly experiment with different ways of generating and manipulating graphics rather than a scalable 2d graphics library, but I don't see any obvious reasons why it couldn't be used as such, so long as you take care to properly separate logic code from rendering code.
If there are better options, let me know.

Processing is certainly cool, but is somewhat specialised towards visualisation / interactive animations. It also has it's own mini-language designed for visualization applications. While it is possible you could make a decent game using it, you might start running into performance issues as this is going outside its usual usage.
For a decent-sized game I expect you will ultimately want to use OpenGL directly, in which case LWJGL might be a better option.
Ultimately, you probably need to prototype using both and figure out what works best. As a rough benchmark, you will want to render a full screen of tiles plus 1,000 sprites at 100+ FPS with less than 20% CPU. If you can demonstrate that processing can handle that then you may be fine.
Other options that you can consider:
Swing - good for simple 2D games. Has the advantage that it is built-in to the standard Java distribution and has lots of good tutorials. Wasn't really designed for games but works fine providing you aren't too demanding.
JavaFX 2.0 - roughly intended to plat in the same space as Flash (rich internet applications). Looks pretty cool, but is still fairly new. Again, probably fine for simple Flash-style games.

I would be careful of using processing for this. I'm not sure about PC, but on the Mac Processing can have pretty hi CPU usage, depending what you are doing. So if your game is cross platform there might be a better option. If it's an online game why not use Flash? The scripting languages are not too far apart and in the book 'Processing: A programming handbook for visual Designers and Artists' (Casey Reas & Ben Fry) there's a handy little section at the back (pages 686 - 691) showing the comparative syntax of Processing, Java, Actionscript & Lingo that would be a useful way of getting you started.

JavaFx 2.0 Game Engines/Frameworks -- How will JavaFx 2.0 change Java gaming?

I realize JavaFx 2.0 has only been out for a short time but was hoping someone is aware of an FX 2.0 game engine ( or even such a project in open source development )? I've been unable to find one- so if you do please point me in the right direction.
I'm also wondering how JavaFX2.0 will change java game programming. From what I've read and the small experiments I've made I can definitely say it is much more pleasant to code in. And I believe it runs on a faster hardware accelerated graphics engine than regular Java swing or awt based stuff. But is it complete enough to support an entire game framework of any complexity?

JavaFX is great for simple browser based / 2D games - the kind of areas where Flash is currently most common. Reasons:
Great performance for 2D apps (good use of hardware acceleration under the hood)
Very easy to skin with CSS - web designers will love this
The new JavaFX 2.0 API is very usable from pure Java (or other JVM languages like Scala, Clojure)
Cross platform, so can reach the largest possible audience
It's unlikely to be suitable for complex / high performance 3D games where you will need a proper OpenGL game engine like jMonkeyEngine.
I think the jury is still out with respect to the games in the middle ground (shoot-em-ups, 3rd person view RPGs, RTS games etc.). These games don't necessarily need a full 3D engine but do need good, smooth graphics performance. I suspect JavaFX would be fine for these on modern hardware, but I'd strongly suggest doing a quick prototype just to check the performance meets your requirements.

javaFx is not much more than a GUI toolkit like Swing, but with some extras. It is already possible to render a proper game engine into a javafx node. Here is a dome showing this.
http://www.java-gaming.org/topics/lwjgl-javafx-integration/27801/view.html.
But this does not solve the problem to lock the mouse for first person like games.

Slick2D vs Straight LWJGL

I've been delving into game programming with Slick2D, and I've began to wonder if in the long run, knowing LWJGL would be more helpful. On one hand, Slick2D is fast and simple, but it seems LWJGL is more adaptable in the sense that it has both 2D and 3D capabilities. For someone who is intermediate in java, and wants to make games, would it be worth the additional effort to learn LWJGL right off the bat?

I don't think the two are really related. I mean, I know Slick is built on top of LWGJL, but that's not what I'm getting at here.
Slick exists to take advantage of the hardware graphics and sound acceleration, and to give that power to 2D games with a set of objects and classes that make sense for 2D games (sprites and tilemaps, as opposed to geometric models and 3D coordinate space). That's it - that's its mission, and it's built to be awesome at solving that problem. The fact that Slick is based on LWJGL is simply a matter of LWJGL being a library upon which you could build something like Slick. In the history of people trying to make games in Java, graphics performance had always been a major problem to getting anything of quality out on the market. Slick essentially removes that hurdle for 2D games on the desktop (and hopefully on Android, someday).
When considering Slick vs. LWJGL, it's a "right tool for the right job" sort of thing. If you're building a 2D game in Java, Slick is an awesome way to go. If you're actually building a 3D game (or a game with a top-down 2D sort of view, but you have a requirement to actually render your scenes in 3D), then LWJGL may be your best starting point.
If, however, you're building a 2D game, and you think it's worth your time to build it in LWJGL, 99% of what you're going to build in order to make that work is going to be Sprites, animation, key input, pathfinding, and sound. Slick has already built these things for you - you're pretty much guaranteed to be reinventing the wheel, and as well intentioned as you are, you won't do it as well as the developers who have spent years working on Slick. 2D game rendering is a solved problem - don't waste your time. Unless you're seriously into rendering engines (I'm not even talking about game engines where you spend your time working out game play and mechanics, but actual rendering technology) you're going to find it more than a little frustrating. The frustration won't come from it being too difficult a problem to solve (you can certainly solve it), it's just that you'll spent months building it, and when you're done you'll have some subset of the features already included in Slick, but no game to show for it. The smart people that made Slick already solved the elements of a 2D game engine in Java for you - take advantage of their work and don't spend months trying to build something that's right there in front of you.
To make one final analogy, the huge explosion of gaming on the PC in the early 90's really happened when DirectX hit the market. Sure there were video games around all the way back to the Atari, the Apple ][, the Commodore, etc., but there was an explosion, an absolutely huge jump in games and technology when DirectX came aboard and saved developers from writing their own drivers for sound and video. That's literally what developers had to do back then if they were writing games - write or license individual drivers for each sound and video card that they wanted their game to run on. DirectX gave developers a chance to stop worrying about that - to only worry that hardware was "DirectX compatible" to a certain version, and was minimally powerful to deliver the performance they needed, and that was it.
It's hard to explain just how big this was - but if you're developing 2D games in Java - Slick (or one of the other game tools out there) is your DirectX!

Really nice answer from normalocity, I just want to say if you want to really optimize your drawing scene in Slick2D, you need to know than standard draw method of Slick use a glBegin/glEnd.
With a lot of sprite (~10 000), this method is really slow. To avoid this problem you can use drawEmbedded method on a very big sprite-sheet or make your own method with LWJGL. The best is to make a VBO rendering => http://lwjgl.org/wiki/index.php?title=Using_Vertex_Buffer_Objects_(VBO).