We Keep Coding

Do we need to set Windows environment variables for Java updates anymore?

I've been setting Windows environment variables (like JAVA_HOME) every time I installed a Java update. (As per Environment variables for java installation).
However, I've recently noticed that Java updates add C:\ProgramData\Oracle\Java\javapath; to the System Path (not the User Path). I removed JAVA_HOME, etc from my User Path, and java -version seems to work from any directory.
Does that mean that it is not necessary to do that simple but annoying task with each Java update?

That depends on what you are trying to do.
Generally, you don't need JAVA_HOME to run a Java app. Adding the location of the Java binaries to the PATH is sufficient for Windows to find and execute them.
However, e.g. a lot of application servers like Tomcat and build tools like Gradle will use JAVA_HOME to determine the location of your Java installation.

Java itself does not use JAVA_HOME. Some third-party things like IDEs and Tomcat do. I've never set it as an environment variable in 20 years.

Personally, I don't even have JAVA_HOME set and I've been developing at this company for 6 years now (and other companies for 10+ years). To me, it tends to get in the way. The last install sets the windows path which generally isn't what my IDE's, Tomcat, JBoss or SOAP-UI support so I just edit all their startup files to choose/set the JAVA_HOME they work with.

Does java use the registry to locate its default jar files?

Target Environment
Windows 7 (6.1)
Java 1.8.0_121 64bit
I recently created a minimal java environment consisting of just the single file java.exe in a newly created, empty directory and successfully ran a simple HelloWorld.class file simply by copying it to the same directory and typing:
.\java HelloWorld
I found this kind of surprising, and wondered if maybe because the version of java I was using (jre 1.8.0_72) had been installed from an .exe file whether there was something in the Windows registry telling java.exe where to find rt.jar and such.
Running the java control panel, you can certainly see java 1.8.0_72 is in there:
I if I used a java version which was NOT installed (i.e. a standalone java version) would I get a different result?

Well, before trying a stand-alone version I think I'll try a computer having NO java on it at all. Same exact set up as before.
Found part of the answer on my wife's Windows 10 computer (which has no java on it):
Clearly, I should copy java.dll somewhere. Think I'll put it in the same directory as everything else (i.e. the same one as the java.exe), and try that.
Nope. Same as before.
So clearly java is looking in the registry to find its .dll.
I've downloaded jre-8u121-windows-x64.tar.gz. I'm going to try the same experiment with that.
Tried the same experiment with java from the tarball above. Exact same symptom. Cannot find java.dll.
Having done a little reading, I see that Embedded Java SE has a way to create custom deployments of java. There appears to be no official analogous mechanism for Java SE for Windows.
Doing a little more reading, I see that there is a mechanism called the Invocation API which can be used to run java, bypassing java.exe. This might be something to try. Might also be time to start surfing the HOTSPOT code.
More on the Invocation API here: http://docs.oracle.com/javase/6/docs/technotes/guides/jni/spec/invocation.html
An intriguing note I also ran into during my reading said this:
Private vs. public JRE - Installing the JDK installs a private Java SE Runtime Environment (JRE) and optionally a public copy. The private JRE is required to run the tools included with the JDK. It has no registry settings and is contained entirely in a jre directory (typically at C:\Program Files\jdk1.6.0\jre) whose location is known only to the JDK.
I read this here: http://www.oracle.com/technetwork/java/javase/install-windows-142126.html
You might try this experiment with THAT jre.

Today I also face same problem .and I found the solution for this go-to your JDK bin copy path from there and peast this path to environment variable path and the priority should be first that mean it should be peast in starting of all path.

Any solution to get the list of smartcards inside OS X?

I am implementing an applet that gets some information from the user, including your name,
is system administrator, machine architecture and more the certificates and smartcards plugged list, all this is for checking the prerequisites of another applet.
In Windows all works perfectly, but I have problems getting smartcards info in MAC (OS X Lion Mountain), probably caused by this bug: Bug DB:- JDK-7195480 : javax.smartcardio does not detect cards on Mac OS X.
I found the following possible solutions (I think):
Use of another library without the bug as https://github.com/intarsys/smartcard-io
I looked at these discussions:
Force the JVM to run in 32bit (-d32) as described in the discussions at apple forums.
Force java applet to run in 32-bit instead of 64-bit JRE
Force VM to launch in 32-bit mode WebStart JNLP
For the first case I have the problem of lib be compiled to version 7, I need it to version 6,
I did not succeed to compile for 6, and the extra JARs are to big (+- 4MB).
For the second case, apparently this does not work on Windows (docs oracle javase 6 docs technotes guides javaws developersguide syntax)
And aparently have some limitations...
Does anyone know another lib (in Java 6) to get the smartcard information?
I need only reader name, card name and ATR.
Or someone would know a way to force the JVM from a Applet (simple method)?
Please, try to be clarified because I am beginner in Java!

..Or someone would know a way to force the JVM from a Applet (simple method)?
We cannot really 'force' the user to do anything (not that we should), but by launching the applet using Java Web Start we can request particular versions of the JRE. Here's a rundown.
Java Web Start - Runtime Versioning
Java Web Start can be used to ensure that an application
gains a certain minimum version of the JRE
(Java Runtime Environment) that it requires to run.
Web start can also be used to ensure a specific
micro-version of the JRE
is available to an application, or that an
earlier major release
is used (e.g. using 1.3, on a system where 1.6 is installed).
Unless the system is correctly configured, the user might be
prompted for download.
Minimum Version
Java web start can be used to ensure a Java project is launched
with a particular minimum version of Java. For example, if the application
uses generics, but nothing beyond what is available in Java 1.5, the
JNLP deployment descriptor might include a section that says..
..
<resources>
<j2se version='1.5+'>
...
</resources>
Micro Version
Besides being able to specify a minimum Java Major version, the
deployer can also mandate a particular micro-version. An example
of where this can be handy, might be seen in changes to JRE's based
on new information about Daylight Savings Time (which can be changed
by regional governments at any time they see the need to change them).
..
<resources>
<j2se version='1.5.0_11'>
...
</resources>
Earlier Version
Web start has a handy feature in that it can allow us to
test applications against specific earlier Java versions.
For example, if the local build environment is based around 1.6,
but an application is supposedly 1.5+, it pays to test the
final product in a 1.5 JRE prior to deployment. Invoking a 1.5
JRE in the 1.6 environment can be as simple as.
..
<resources>
<j2se version='1.5'>
...
</resources>
Note the difference to the first example, which used '1.5+',
whereas this one uses '1.5' - to indicate that only a 1.5
JRE will do.
An alternative version..
..
<resources>
<j2se version='1.5*'>
...
</resources>
Prompt for Download
A problem commonly reported by people deploying applications
via web start, is that they are being prompted to download versions
of Java that are already locally installed.
Even if a specific Java
version is installed, it might not be flagged as being 'available'
for use by web start.
This can be easily fixed.
Open the Java Control Panel.
Select the Java tab and click the View
button of Java Application Runtime Settings.
You might see something like this.
Note which ones are Enabled (right column). This PC is
set up to use
1.6.0,
1.5.0_11, or
1.5.0_08. Neither of the
1.5.0-beta or
1.5.0_01 micro versions is available.
That is purely by my choice - if I needed to test against these
very early 1.5 versions, I could simply enable them as needed.
Ensure any versions of interest are Enabled and the problem
should be fixed. Web start will be able to load that version of the
JRE and use it, without any prompt for download.
If you have versions installed that do not
appear in the User list, click Find to
launch the JRE Finder to
search for them. The (Java 1.6) JRE Finder will
present a dialog with a message along these lines.
In order to launch applications, Java Web Start needs to know
the locations of installed Java Runtime Environments.
You can either select a known JRE, or select a directory in
the file system from which to search for JREs.
A thread
on the web start forum also produced the following comments
from Andy Herrick.
On Windows, the list of available JRE's is populated from
the registry which contains pointers to all the publicly
installed JRE's.
(It will not automatically include private JRE's, such as
those installed by a JDK install, where "install public JRE"
is not selected.).
On unix it will only, by default, contain
the JRE it came with and any installed by java web start or
that came with any previous version of java web start that
had previously been run.
He adds a further note on specifying a download source..
Using either:
<j2se version="1.5*" href="http://java.sun.com/products/autodl/j2se">
or
<j2se version="1.5" >
will get you any 1.5 version available on the system.
If you use the href attribute, you are asking for the particular update release, so..
<j2se version="1.5" href="http://java.sun.com/products/autodl/j2se">
..will only work with 1.5.0_00.

Windows 7 64-bit, Configuring 2 versions of Java

Windows 7 64bit. I have a web based application that needs to use the newest version of java (1.7.0.45) and I have another software install the needs java versions (1.5.0.15 & 1.4.2). I'm just unsure how to set the PATH/VARIABLE for this to work properly.. any help would be greatly appreciated.
I have seen several posts & answers regarding very similar situations to this, but I am just unsure how to make this work.

As mentioned by #Moshe here.
It is absolutely possible to install side-by-side several JRE/JDK
versions. Moreover, you don't have to do anything special for that to
happen, as Sun is creating a different folder for each (under Program
Files).
There is no control panel to check which JRE works for each
application. Basically, the JRE that will work would be the first in
your PATH environment variable. You can change that, or the JAVA_HOME
variable, or create specific cmd/bat files to launch the applications
you desire, each with a different JRE in path. Just like below,
set JAVA_HOME=C:\...\j2dskXXX to change the JAVA_HOME environment.

Can you check whether your OS and java runtime are 32-bit or 64-bit from within your program?

I was told there is a System Environment Property File i could check, however, it hasn't yielded any definite results so far.
Basically I need to see what version of the OS and Java i'm running so I can copy the correct DLLs to the run directory. As always, a better solution is appreciated.

You can check JRE version checkin os.arch property of System class
http://mark.koli.ch/2009/10/javas-osarch-system-property-is-the-bitness-of-the-jre-not-the-operating-system.html

JNLP - Java Web Start - allows for specifying DLL's and shared libraries per architecture. This allows you to do centralized distribution with a local icon for the users to click.