Easy, automated download and installation for Java Runtime

The attached makes adding auto-JRE detection, download and installation easy.

See JREDyna Wiki Page for details


I look forward to comments and suggestions for improvements.

- Kevin

PS - I can't seem to figure out how to get that URL link to work! Here's the link without http just to get it working: nsis.sourceforge.net/Java_Runtime_Environment_Dynamic_Installer

Yeah, you need x number of posts before you can post URL's

Thanks, Anders - that makes sense (although it would have been nice if the forum software issued a warning, eh?)

I spent a lot of time fighting the system trying to get the Wiki page looking right, and the forum post. It's a shame that there isn't an easily accessible primer for this sort of thing (just figuring out how to upload a file for the Wiki took quite some doing). This has to be some level of barrier to entry for folks wanting to share their work. But I know that we all do what we can - and for this particular contribution, I was more than willing to go through the learning curve.

Maybe I should put together a Wiki page on tips and tricks to share solutions on the Wiki :-)

NSIS main page, click FAQ: http://nsis.sourceforge.net/FAQ (At the bottom you will find "Uploading files")

Update for W2k3

Hi,

Registered here just to say -- Windows 2003 seems to require lowercase /s and /l arguments. Otherwise you just get an ugly Windows Installer dialog saying "Invalid command line parameters".

So I changed the ExecWait line to:

ExecWait '"$TEMP\jre_setup.exe" /s REBOOT=Suppress JAVAUPDATE=0 WEBSTARTICON=0 /l \"$TEMP\jre_setup.log\"' $0

And it now works fine. Not sure how to upload yet, but hope that helps.

- Tom

Installer script modification

Hi, Kevin!
I've used your script for my open-source application installer, thank you for your great work. But I had to improve it a little to work on modern OS.
For example, I added check if we' re running installer on x64 so we should
read registry in x64 mode.

${If} ${RunningX64} ;if it's x64 OS

  SetRegView 64 ; change registry view mode for proper x64 JRE detection

 ${EndIf}



  ReadRegStr $1 HKLM "SOFTWARE\JavaSoft\Java Runtime Environment" "CurrentVersion"

  StrCmp $1 "" DetectTry2

  ReadRegStr $2 HKLM "SOFTWARE\JavaSoft\Java Runtime Environment\$1" "JavaHome"

  StrCmp $2 "" DetectTry2

  Goto GetJRE

  ; lots of detection code skipped 

  .

  .

  .

DetectJREEnd:



${If} ${RunningX64} 

  SetRegView 32 ; return to x32 view mode

 ${EndIf}

So, post me a message if you are interested, I 'd like to share my improvements with others and add modified version to nsis.wiki

You do not need to do the RunningX64 test as SetRegView has no effect on a 32-bit OS (you're just adding 2 unnecessary System plug-in calls per usage).

Stu

EolSC - I've thought on this a bit...

There are times when detecting 32 bit JVM is desirable, even on 64 bit systems (for example, we have a number of applications that use 32 bit JNI dlls). To incorporate this, we'd need to be somewhat intelligent about when we do or do not do the check in the 64 bit registry branches.

It seems to me that if your installer is wanting the 64 bit JVM installed, then you probably want the entire installer working with the 64 bit area of the registry. If that's the case, then you should probably be calling SetRegView 64 in the main installer (and not having this call in the area specific to download of the 64 bit JVM)...

Further, explicitly changing the registry view in a library like this could mess people up who *have* set the registry view elsewhere. If we are going to do this inside the library, then we'd have to capture the registry view before and set it back to it's prior state afterwards.

Is there really a need to do this check inside the library itself?

x64 checks

Thanks for your replies, now I understand where I'm missing the point. Surely it was a bad idea to mess up library code, I'll move all checks to main installer and clean up unnecessary checks.

Hah - in this particular case, it's probably best to do the check elsewhere, but there is *nothing* wrong with messing with the library code, trying out new things, then discussing them in these forums. That's where cool new ideas came from, and I'm delighted that you are willing to poke at it and share your results!

This thread (and the wiki entry) haven't been updated for quite some time, but JREDyna is the best NSIS Java detector/updater we found. FWIW, I thought I'd share what we've added to automatically discover the latest JRE version.

This uses the same method Oracle's own updater uses to determine the latest version, so hopefully it'll work for some time. Just in case, though, there's a default fallback URL (that can be defined in the calling .nsi, like JRE_URL in the original version--but a default default is used if it hasn't been declared). Note the filename is adjusted since the *-au.exe file that the updater uses only works to update Java and doesn't seem to work if you're installing from scratch. Unfortunately that introduces another possible point of failure where Oracle might change something.

Being required to parse Oracle's XML means there's more dependencies, though: OnlineUpdate and the XML plug-in

Defines/includes ...

  !ifndef JRE_DECLARES

  !define JRE_DECLARES



  !include "TextFunc.nsh"

  !insertmacro ConfigRead

  !include "WordFunc.nsh"

  !insertmacro WordReplace

  !include "XML.nsh"

  !include "OnlineUpdate.nsh"

  !insertmacro UpdateXml



  !macro CUSTOM_PAGE_JREINFO

    Page custom CUSTOM_PAGE_JREINFO

  !macroend

  

  !ifndef JRE_VERSION

      !define JRE_VERSION "1.8"

  !endif

  !ifndef JRE_UPDATE_XML

      !define JRE_UPDATE_XML "https://javadl-esd-secure.oracle.com/update/1.8.0/map-m-1.8.0.xml"

  !endif

  !ifndef JRE_DEFAULT_URL

      !define JRE_DEFAULT_URL "http://javadl.sun.com/webapps/download/AutoDL?BundleId=211968" ;JavaSetup8u101.exe

  !endif

  Var JreUrl

Starting at the downloadJRE label (originally line 94)...

downloadJRE:

  DetailPrint "Checking for latest version of the Java Runtime Environment ..."



  ${UpdateXml} "${JRE_UPDATE_XML}" "/java-update-map/mapping[-1]/url" $R1

  ${If} "$R1" != ""

      ${UpdateXml} "$R1" "/java-update/information[1]/url" $R1

      ${WordReplace} "$R1" "-au.exe" "-i586-iftw.exe" "}" $R1

      ${If} $R1 != ""

	      StrCpy $JreUrl $R1

      ${Else}

          !ifdef JRE_DEFAULT_URL

              StrCpy $JreUrl "${JRE_DEFAULT_URL}"

          !endif

      ${EndIf}

  ${Else}

      !ifdef JRE_DEFAULT_URL

          StrCpy $JreUrl "${JRE_DEFAULT_URL}"

      !endif

  ${EndIf}



doDownload:

  ${If} "$JreUrl" != ""

      DetailPrint "About to download JRE from $JreUrl"

	  

      GetDlgItem $3 $HWNDPARENT 1

      ShowWindow $3 ${SW_SHOW}



      Inetc::get /caption "Downloading JRE ..." /nocancel "$JreUrl" "$TEMP\jre_Setup.exe" /end

      DetailPrint "JRE Download Complete"



      Pop $0 # return value = exit code, "OK" if OK

      DetailPrint "Download result = $0"



      StrCmp $0 "OK" downloadsuccessful

  ${Else}

      StrCpy $0 "Couldn't find URL"

  ${EndIf}

  

  ;Couldn't find URL or couldn't download. If the URL isn't already the default, give the default a try.

  ${If} "$JreUrl" != "${JRE_DEFAULT_URL}"

      StrCpy $JreUrl "${JRE_DEFAULT_URL}"

      ${If} "$JreUrl" != ""

          DetailPrint "Trying default URL ..."

	      Goto doDownload

	  ${EndIf}

  ${EndIf}



  MessageBox MB_ICONSTOP "There was a problem downloading required component - Error: $0"

  Abort

downloadsuccessful:

Hopefully someone finds this helpful!

Please post the (whole) code on Wiki.

Forum is not the best because this may be lost in history etc.

Thanks! 🙂