Well, I recently installed Arch Linux, and am now ready to continue development (starting with a pixel/programmer-art application 8)).
The only Java available from the Arch official repositories is SE7.
While I can install Java 6 with a little more work, I’m wondering if I should.
Since Mac+LWJGL+Java 7 is working, is it safe a good idea to switch (back) to Java 7? or is it not widely used enough yet?
Install which version is available in your distro and you can target a lower version since I too think that Java 7 is still not widely used yet. I always target the least version of java I had to check in eclipse but my JDK is version 8. Here’s some reasons for not using the latest java in user’s type of mind.
These are the main reasons. Also an article Choosing between Java version 6 or 7 stated “When it comes to Java, the latest is probably not the greatest.”
So install a newer version if you have to but deploy to an older JVM.
Java 6 it is then.
Now I need to do a bit of hacking around to install Java 6…
I love Arch Linux. 
EDIT: Eclipse says I need a compatible JVM for 1.6 compliance. Not sure what that means though. Whether it means Java 7 is compatible and works, or is warning me to install Java 6.
A good reason to no longer use Java 6 is that it is out of support.
We’re transitioning to Java 7 only. We will ultimately drop support for OSX10.6 or below in order to do this. It’s getting a little long in the tooth though.
Cas 
Is there something wrong with Java7 + OSX10.6 ? I though that the latest LWJGL fixed the issues of java7 and OSX.
Java7 just doesn’t run on OSX10.6 or below.
Cas
Not this one again! : Particularly given that the OP mentioned Linux, this statement is incorrect. Free support for Oracle’s proprietary Java 6 is ended (though not paid support), but that doesn’t apply to either OpenJDK or (I believe) Apples’s JDK.
Mind you, a recent security update of OpenJDK 6 completely broke things - multiple EDT’s at once anyone? :o
Java 1.7 will work, however the correct practice for compiling towards older bytecode is to use the -source setting for the older version and to set the bootclasspath to compile against the older version of rt.jar. However if you don’t point the bootclasspath to the older JDK javac will do it’s best to use the old language rules combined with the new libraries which can cause subtle bugs and bytecode that points to code that doesn’t exist in the older libraries. (Source for that info) Now since that is just a warning you can probably get away with it and I never experienced any issues. However since I use an ant script to build my projects for actual deployment I just installed the latest JDK 6 build and told my ant script to run using that instead of JDK 1.7.
I use 7 only. I don’t like having multiple instance of JDK installation.
Thanks a lot, I didn’t know that … this allowed me to understand why my game was not running on OSX 10.6 and older versions
Just set your compilation target 1.6 on Eclipse.
You’re going to need a 1.6 jdk installed though, iirc.
nsigma wrote a bug report about a very big regression in OpenJDK 1.6, a real nightmare, several event queues, … 
Rather use OpenJDK 1.7.
The problem is that I was trying to run the game with an embedded JRE 7 under OSX 10.6 which just failed to create the display ( the rest was surprisingly working … ). I was already compiling in 1.6 so it was just a matter of JRE. Now for OSX I use the default system JRE for OSX 10.6 and lower, and my embedded JRE 7 for OSX 10.7 and higher
Exactly what we do (have a look at our Mac downloads - nifty self-expanding JRE etc with fallback)
Cas
Yep in fact I already have and got a lot of inspiration from your Droid assault launch script I did not do the self expanding JRE thing as the game size will be quite huge for me anyway
By the way, I plan to use an embedded JRE too, JogAmp Runtime Environment alias Project Ji Gong, based on OpenJDK 1.8 EA. Yeah! I’m gonna set fire to AWT ;D
Now you mentioned it. It’s not only 6 or 7 anymore, don’t forget the 8 :emo: