Secure Cipher Suites supported by JDK versions I'm a n00b to cryptography.  I've been searching through oracle's java docs, ssl labs, googling and more googling attempting to find an up to date list of cipher suites considered secure for the latest updates of Java SE 6 (I know its old), Java SE 7 and Java SE 8. I've found plenty of outdated info which is not useful to me. 

I understand the basic concepts and ciphers that together make a cipher suite- key exchange, bulk encryption and MAC. I also have a high level understanding of the TLS protocols. 

If someone can point me to an up to date resource(s) I'd really appreciate it. Deadlines are looming. 

To clarify- This isn't a programming question. It is strictly focusing on secure cipher suites. I'm not implementing any of this in code. It is simply a list of secure ciphers related to Java that I'm compiling.
(Meta: if we're going to improve formatting might as well improve content too. However, I haven't looked at at 10 yet; I'll try to come back and re-edit when I have time to do so.)
Java Cryptography Architecture (JCA) is designed around the concept of replaceable providers. Originally (in the 1990s) this was necessary to easily support US and limited 'foreign' versions with a single codebase.
(This applies to all crypto: codesigning and other things as well as SSL/TLS.)
If you use the Sun-now-Oracle providers (which is the case if you use the 'standard vanilla' JRE or JDK packages from Sun-now-Oracle) or if you use the open-sourced equivalent OpenJDK packages in at least some Unix distros, then the official documentation is at http://docs.oracle.com/javase/8/docs/technotes/guides/security/SunProviders.html#SunJSSEProvider -- and has been there or the corresponding 7 and 6 and 5 directories for a long time.
(Update: Java 9, Java 10.)

In summary, and expanding a bit on some points that may be unobvious:
Protocols

Java (JSSE) 6 implemented only the SSLv3 and TLSv1 (meaning 1.0) protocols. There is also a protocol name SSLv2Hello but this is not an actual protocol, rather the option to use backward-compatible negotiation as per rfc2246 or rfc4346 E.1.

Java 7 and 8 implemented SSLv3 through TLSv1.2, but SSLv3 was disabled in updates beginning Dec 2014 because of POODLE. (6 was past end-of-life and so was not updated, at least not in public/free versions.) Although 7 implements 1.1 and 1.2, on client side it does not enable them by default; 8 does. 7 and 8 still implement SSLv2Hello, but do not enable it on client by default.

In the 2000s there were still some SSL2 servers around, and using SSLv2Hello allowed you to get a more specific error when encountering them, but by now they should all be gone (and SSL3 as well) so there is no good reason to enable SSLv2Hello. If you are stuck running on Java 6, it may be worth the trouble to disable it, because modern systems may implement a rigid no-SSL rule that prohibits any SSL2-format hello, even when it would allow negotiation to an otherwise acceptable TLS version. Plus, if you want to enable ECC on 6 (see below), ECC negotiation may not work (or not well) without extensions while SSL2-format doesn't have.


Cipher suites
JSSE 6 and 7 implement (AFAIK all) public key and Kerberos cipher suites from TLS1.0 and 1.1 (which are the same), although the EXPORT and NULL (!) and anon and KRB5 ones, plus in 7 those using original (single) DES (versus 3DES), are disabled by default. The first three were designed to be insecure, and the last has become so, and they should not be enabled. Suites using Kerberos for key-exchange can be secure but it requires special infrastructure, so if you don't already know about Kerberos you probably can't use it.
But the ECC suites can actually be used only if the JVM has a (separate) cryptoprovider for the needed ECC primitives, which Sun/Oracle JRE/JDK 6 does not but 7 up does (SunECC). You can add a third-party ECC provider to 6; my favorite is BouncyCastle. OpenJDK may be more variable; in particular RedHat (hence CentOS, Fedora, SL, etc) packages used to exclude ECC crypto from (AFAIK all) crypto/security programs even when it was provided upstream, although I believe these have now been fixed.
Also, the cipher algorithm RC4 has become seriously weakened by attacks in recent years and since 2015 is officially prohibited although not everyone implemented this change promptly -- or at all. 8u60 and up disable it using a setting configured in JRE/lib/security/java.security which you can change if you need to, and 9 similarly in JRE/conf/security/java.security.
TLS 1.2: SHA2 and GCM suites
JSSE 7 also implements the CBC-SHA2 suites in TLS1.2; 8 adds the GCM suites in TLS1.2. GCM is one form of AEAD (Authenticated Encryption with Additional Data) which is now considered superior to all former TLS cipher suites, which combine a cipher with separate HMAC in the more vulnerable order MAC-then-Encrypt. GCM suites should be preferred when possible (in 8 up).
SCSV
In addition, 6 starting with 6u22, and all versions of 7 and 8, implement a cipher suite name TLS_EMPTY_RENEGOTIATION_INFO_SCSV which is not actually a cipher suite, but an option to implement rfc5746 using the (registered) pseudo cipher suite value; if 'disabled' JSSE client still supports rfc5746 but uses the extension field instead. In 2010 the SCSV was slightly more interoperable/robust than the extension; today it usually doesn't matter.
Strength Policies
Sun-now-Oracle JREs and JDKs until 2017 install with a default 'policy' that prohibits symmetric encryption over 128 bit strength; for SSL/TLS this has the effect of disabling cipher suites using AES-256 (in either CBC or GCM). To use AES-256 on these you must download and install the Unlimited Strength Jurisidiction JCE Policy applicable to your major version. Only 8 is still on the download page (but may not be much longer); older versions used to be in the archive but I no longer see them. Update: 8u161 and 8u162 in 2018, and 9.0.0 in 2017, remove this obsolete policy restriction, and allow AES-256 out of the box; OpenJDK (AFAIK all versions) never had this misfeature in the first place.
Server keys limit available cipher suites
On server side, of course, a public key suite can be agreed only if the server's keystore (or more precisely keymanagers, normally derived from a keystore) contains a privatekey with certificate (chain) for the applicable publickey algorithm. For example, using an RSA-based cipher suite requires an RSA key and cert. In particular, keytool by default generates a DSA privatekey and selfsigned certificate; this supports only ciphersuites with DHE_DSS key exchange. JSSE supports keymanagers containing multiple key+cert pairs of different types, although some applications configure only a single keystore entry (alias) and can't benefit from this.
For ECC (if supported, per above) in addition the curve used must be among those offered by the client; this is rarely a problem for keytool generated keys since it uses the widely supported curves P-256 P-384 P-521, but may matter if you generate your key by other means.
Other providers
IBM Java replaces the Sun/Oracle providers with IBM providers, and I don't have relevant experience with them. And of course you (or anyone) can write your own provider(s) and substitute it(them) in which case you are on your own.
Update: recently BouncyCastle releases began including a provider BCTLS which is an alternative to JSSE, and provides a modern set of features, depending (only) on the BC version, that work the same on all Java versions back to 5. (BC had implemented TLS
years earlier, but using a separate and incompatible API; with BCTLS you just instantiate your SSLContext from BCTLS instead of JSSE and the rest of your code can stay the same.)