Relying on an installed JRE to be correct doesn’t make sense outside of a controlled corporate environment where all the desktops are locked to a specific version. In which case, you should ask this question of the person who controls that environment.

For a mass-market Java desktop application, you should use an installer or launcher that bundles the JRE you want them to be using, or set up Java Web Start (JAWS).

Note that if you actually physically distribute a bundled JRE, you have to comply with the license terms. I am not a lawyer, but those shouldn’t be problematic for most purposes. If you are in a situation where you have a legal team, you should of course run it past them.

For a developer or other technically-oriented tool, it is generally preferable to publish the jars on Maven Central, so distribution and download is entirely automated. This is one case where sticking to older Java versions is something of an advantage, as it enables their use in corporations locked down to an older version.

But I wouldn’t worry about that too much for a project started today.

Finally, if all the above is too much work, you can just publish the source on github or bitbucket and let the user build it themselves.

Java 6 is unsupported by Oracle, so don’t use that.
Java 7’s support ends on April 15th, so you know.
Just use Java 8 and save yourself the hassle.

See Oracle’s support roadmap for more info.

Another point to consider is that, depending on the size of your project, what version of Java will be out and what will be obsolete. For most sizable projects, it would be wise to work with the current ‘out of beta/alpha’ version, (in this case Java 8) which may or may not be current when you release.