anchor.diff:  :: The JRE installer must be in a place the script can find it (e.g. network path, same directory, etc)
   :: JRE 64-bit reinstaller
   set JAVA_LOCATION_x64=%~dp0
  -set JAVA_BINARY_x64=jre-8u31-windows-x64.exe
  +set JAVA_BINARY_x64=jre-8u144-windows-x64.exe
   set JAVA_ARGUMENTS_x64=/s
   
   :: JRE 32-bit reinstaller
   set JAVA_LOCATION_x86=%~dp0
  -set JAVA_BINARY_x86=jre-8u31-windows-x86.exe
  +set JAVA_BINARY_x86=jre-8u144-windows-x86.exe
   set JAVA_ARGUMENTS_x86=/s
   
   
  
positive.code: :file_cleanup
  call :log "%CUR_DATE% %TIME%   Commencing file and directory cleanup..."
  
  :: Kill the accursed Java tasks in Task Scheduler
  call :log "%CUR_DATE% %TIME%   Removing Java tasks from the Windows Task Scheduler..."
  if exist %WINDIR%\tasks\Java*.job del /F /Q %WINDIR%\tasks\Java*.job >> "%LOGPATH%\%LOGFILE%"
  if exist %WINDIR%\System32\tasks\Java*.job del /F /Q %WINDIR%\System32\tasks\Java*.job >> "%LOGPATH%\%LOGFILE%"
  if exist %WINDIR%\SysWOW64\tasks\Java*.job del /F /Q %WINDIR%\SysWOW64\tasks\Java*.job >> "%LOGPATH%\%LOGFILE%"
  echo.
  
  :: Kill the accursed Java Quickstarter service
  sc query JavaQuickStarterService >NUL
  if not %ERRORLEVEL%==1060 (
  	call :log "%CUR_DATE% %TIME%   De-registering and removing Java Quickstarter service..."
  
negative.code: 
  
  :::::::::::::::::::::::::
  :: UNINSTALLER SECTION :: -- Here we brute-force every "normal" method for removing
  :::::::::::::::::::::::::    Java, then resort to more painstaking methods later
  call :log "%CUR_DATE% %TIME%   Targeting individual JRE versions..."
  call :log "%CUR_DATE% %TIME%   This might take a few minutes. Don't close this window."
  
  :: EXPOSITION DUMP: OK, so all JRE runtimes (series 4-9) use certain GUIDs that increment with each new update (e.g. Update 66)
  :: This makes it easy to catch them through liberal use of WMI wildcards ("_" is single character, "%" is any number of characters)
  :: Additionally, JRE 6 introduced 64-bit runtimes, so in addition to the two-digit Update XX revision number, we also check for the architecture
  :: type, which always equals '32' or '64'. The first wildcard is the architecture, the second is the revision/update number.
  :: Beginning with JRE versions over 99 (JRE8 was first major version to have subversions go over 99), the GUID string "2F8__", which identified architecture, switched to "2F__", presumably to make room for the new 3rd digit in the version identifying section. You can see this in the JRE8 portion below.
  
  :: JRE 9
  call :log "%CUR_DATE% %TIME%   JRE 9..."
  :: Wildcards aren't used here (yet) because we don't know which portion of the GUID will change with the first "Update xx" release.
  :: Script will be updated when the first Update to series 9 is released by Oracle
  %WMIC% product where "IdentifyingNumber like '{DA69628A-2608-5BA9-8749-1EE90CB29D95}'" call uninstall /nointeractive >> "%LOGPATH%\%LOGFILE%"
  %WMIC% product where "name like 'Java 9%%'" uninstall /nointeractive
  
  :: JRE 8
  call :log "%CUR_DATE% %TIME%   JRE 8..."
  %WMIC% product where "IdentifyingNumber like '{26A24AE4-039D-4CA4-87B4-2F8__180__F_}'" call uninstall /nointeractive >> "%LOGPATH%\%LOGFILE%"
  :: This line catches any version above 99 since it's three characters instead of two. Oracle also dropped the "8" from
  :: the last part of the GUID, so instead of "2F8__" it's now "2F__", presumably to make room for the 3rd digit on the right
  %WMIC% product where "IdentifyingNumber like '{26A24AE4-039D-4CA4-87B4-2F__180___F_}'" call uninstall /nointeractive >> "%LOGPATH%\%LOGFILE%"
  
  :: JRE 7
  call :log "%CUR_DATE% %TIME%   JRE 7..."
  