The duplicate lines must be an editting or perhaps text-generation glitch of some kind, because in that format the ciphersuite should be a unique key. There are also four lines for TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 -- all wrong!
You aren't specific, and I certainly see some other errors in the page you link, but differences about JSSE across different JDK versions could be correct. In particular:
Java 6 JSSE supported some suites using EC (Elliptic Curve) algorithms, though not the one you name, and they were even enabled in the sense of being in JSSE's 'enabledCiphers' list. But they were actually used in the protocol only if the JVM included a cryptoprovider with EC (including ECDH and ECDSA) primitives, as described in the note above table 4-11 on the page you link, and Sun-then-Oracle j6 did not include such a provider out of the box, but it could be added, and other builds could be different (which was a major point of the JCA design way back to its beginning).
Java 7 JSSE implemented TLS 1.1 and 1.2, which adds some additional suites including the one you name (since it uses AES-CBC and SHA384); by default it enabled these protocols (and thus this suite) only on server side not client side, but this could be overridden. Oracle j7 added an EC provider (SunEC) so that 'enabled' EC suites could actually be used; again other builds could differ. (RedHat OpenJDK in particular removed EC for several years.) However the free Oracle versions of j7 (like j6 and earlier) were subject to the 'limited crypto policy' restrictions originally created to satisfy arms export regulations in the 1990s, which primarily disabled all AES-256 suites by default; this could be fixed by downloading and installing the 'unlimited jurisdiction crypto policy' jars, about which you can find many stackexchange Qs dating from before 2018. The then-separate OpenJDK releases did not have the limited-crypto restrictions, and I believe some of the Oracle paid-support versions (after 7u80 in 2015) also changed this, but I don't pay for support.
Java 8 added some more TLS1.2 suites (using AES-GCM), and enabled TLS1.2 (and thus the SHA384 suite you name) on client by default. Starting with 8u151 in late 2017, it also removed the limited-crypto restriction so that AES-256 is enabled without an additional download.
Java 9 and 10 started out with TLS1.2 enabled and no limited-crypto, and did not make significant changes in this area TTBOMK. Java 11 adds TLS1.3, which radically changes the whole concept of ciphersuites; instead of specifying the whole range of keyexchange, server auth, cipher and MAC and PRF, they now specify only cipher-and-MAC (always combined because now only AEAD ciphers are allowed) and PRF.
RC4 used to be trusted, and suites using it enabled; for a while during BEAST in 2011 they were even recommended. But advances in cryptanalysis made them insecure and they were officially forbidden by rfc7465 in 2015. This just missed the last free release of Oracle j7 (7u80) but to my understanding later paid-support Oracle versions, and OpenJDK versions, did disable RC4. Java 8 (IINM both Oracle and OpenJDK) disabled it starting with 8u51, and 9 10 11 from their first releases.
Similarly SSLv3 was badly broken by POODLE in 2014, and thus disabled in 7 from 7u75, 8 from 8u31, and 9 10 11 from outset. (SSLv2 is not a security issue; the pseudoprotocol SSLv2Hello implemented by JSSE is not actual SSLv2 and JSSE has never implemented actual SSLv2. However, SSLv2Hello was a good idea only in the early 2000s when there were still v2 servers in the wild; nowadays it it is not needed and should not be used because it restricts features that use hello extensions like SNI and sigalgs, which are now more and more important.)
If there are any inconsistencies that does not explain, please feel free to ask a more specific question.
PS: note that Oracle 9 and 10 are officially no longer supported, because they were not designated 'long-term' under the new model and 11 has now been out for several months. And Oracle 8 similarly is now officially paid-support-only for commercial. But they still actually work, and of course the source is still available so open-source builds are not affected.