Easy, automated download and installation for Java Runtime

[trumpetinc]

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

[Anders]

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

http://nsis.sourceforge.net/Java_Run...amic_Installer

[trumpetinc]

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 :-)

[Anders]

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

[tdcolvin]

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

[EolSC]

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.

code:
${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

[Afrow UK]

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

[trumpetinc]

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?

[EolSC]

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.

[trumpetinc]

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!