Skip to main content

deployJava.js for desktop applications?

8 replies [Last post]
cowwoc
Offline
Joined: 2003-08-24

Hi,

Is there an equivalent of deployJava.js for desktop applications? At minimum, I'd need access to:

getJREs()
installLatestJRE()
installJRE(requestVersion)
versionCheck(versionPattern)

from a Java library, though it would probably be useful to convert the remaining functions too (excluding the applet-specific ones).

I use NSIS to install my desktop application and the installer must ensure that Java 1.5 update 2 and up is installed, and if not download and install the latest version.

Thanks,
Gili

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
cowwoc
Offline
Joined: 2003-08-24

> Not really, you have to have Java to run Java.

Not if you provided a command-line application like pack200.exe. Installers would invoke it much like you would call an API. For example:

DeployJava.exe -install requestVersion
DeployJava.exe -getJREs # outputs a list of space-separated strings
etc

> Besides, now with the new design of Webstart its
> makes perfect sense to deliver your app using that
> and then all you need is the deployJava.js script.

I'm sorry, but as great as Webstart is it's simply not an option for my application (and I suspect others). Why? Because at it's current development rate it will take Sun no less than 10 years to add all the features I need. It's not that it takes a long time to do so, it's that Sun has treated Webstart as a low-priority item.

I'll name some requests I've made over the years:

- Ability to launch an application without displaying a splash-screen (or progress bar). Essentially I'm asking for a "silent" startup mode. This is necessary for applications that launch when the user logs into the system, the kind of applications that launch and stay dormant with a tray-icon. I believe this is related to http://bugs.sun.com/view_bug.do?bug_id=6297222 and http://bugs.sun.com/view_bug.do?bug_id=4851057

- Ability to install multiple shortcuts with different command-line options at different locations. For example, I'd have one command-line for the desktop icon and another one in the Startup folder. One command-line would tell my application it is being launched by the OS (so it should run in silent mode), another one would tell it that it is being launched by the user (so it should display menus). This is related to http://bugs.sun.com/view_bug.do?bug_id=6297222 mentioned above.

- Fix support for native libraries: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4491398 (this has been open since 2002!) and http://bugs.sun.com/view_bug.do?bug_id=6191612

My application requires every single one of the above bugs to be fixed before I can use Webstart. I seriously believe that anything less will annoy the users so much they will uninstall my application.

It's hard enough getting Sun to fix one bug you really want fixed, not to mention multiple RFEs along the way. To make matters worse, the evaluations of some of the above issues indicates Sun *never* plans on adding certain features (like different command-line options).

I would seriously like someone from the Webstart team to contact me so we can discuss these issues and hopefully get some movement in the right direction.

Gili

zauberer
Offline
Joined: 2006-08-26

Ok, I was unaware that you were wanting features that go way beyond what Webstart was designed for. One thing to keep in mind is that Webstart is a Reference Implementation of the JNLP standard. Its always been my opinion that anytime Sun (or any other company) creates a standard and a reference implementation they are hoping someone will come along and create a good implementation. Sometimes that happens, sometimes it don't. I know this is not what you want to hear but you could create your own JNLP implementation (following the theory of OpenSource, you could share with the rest of us that impl).

Sounds like what you are requiring demands a full installer application. You could then use Webstart to deploy your installer. That's what Sun does, btw. That's how you install the JDK/JRE using the Online Installer option. In that case Webstart is really just providing easy, remote access to, and current version of your installer, as well as making sure you have the right JRE installed.

Also keep in mind that Sun developers come from the UNIX world and in that world installation of programs has always been pretty much a nightmare, way worse than other platforms. UNIX guys are command line junkies, always were.

I too would like to see Webstart become a full Java App Installer but I won't hold my breath waiting for it. You could always plop down that $Grand and go for InstallShield.

cowwoc
Offline
Joined: 2003-08-24

You bring up an interesting point. I never considered using Webstart to launch an installer, as opposed to the actual application. The Webstart documentation is a bit guilty on this front. If Sun expects developers to be doing this sort of thing I would suggest they modify the documentation to mention it.

I'll give your idea some thought and figure out whether it solves my problems.

Thank you!
Gili

zauberer
Offline
Joined: 2006-08-26

Wow, I was way off. InstallShield/InstallAnywhere is now $2.5K - $4.3K ! Good luck.

zauberer
Offline
Joined: 2006-08-26

Not really, you have to have Java to run Java. Besides, now with the new design of Webstart its makes perfect sense to deliver your app using that and then all you need is the deployJava.js script. Put it on your web server and reference one of its functions in your HTML using SCRIPT. It turns out to be extremely simple now.

If you are delivering via physical media then just put an HTML file on the disk and the javascript too. Make that your readme file or part of your installer. Thats better anyway than putting the JRE on your disc, unless you need an exact version of Java, but even that situation is handled properly by Webstart now.

demonduck
Offline
Joined: 2008-03-14

RE: deployJava.js

I read the page:
https://jdk6.dev.java.net/deployment_advice.html#JavaScript_used_for_dep...

I ran the example applet:

https://jdk6.dev.java.net/Java2DApplet.html

Runs great. But I don't see a real advantage over using just the plain old applet tag. An applet tag is way smaller than the 31kb of deployJava.js. My applet is 31kb. Why do I need all this extra stuff. Does it do anything really useful that isn't done with the applet tag?

Is there a document that explains the advantage of using deployJava.js and documents and gives examples of how the functions in deployJava.js can be used to my advantage?

I do not intend to ever use Webstart. Too complicated and overkill for my applet.

zauberer
Offline
Joined: 2006-08-26

Wow, where do I start. I need to get you those links. Once you read that it will all be very clear.

https://jdk6.dev.java.net/deployment_advice.html
https://jdk6.dev.java.net/testDT.html

Did you say that you read the Deployment Advice? If so then you should already have your answer.

Now, even the smallest Applet can take advantage of the deployJava.js script. What you get out of that is, a comprehensive browser check and comprehensive JRE check. This comprehensive check is exactly what has been missing on 90% of the web pages out there and the source of many end-users' angst over Java. Just one example, in the past, devs had to go get the special html code to put the download Java button on their web page and then figure out the magic JavaScript that detected whether or not Java and the right version of Java was installed, and it never worked in all the browsers! No longer necessary, the JavaScript does all of that now.

Download size now-a-days is much less of an issue unless YOU created something really big. J6u10 (or is it already in J6?) adds some features (e.g. JAR Indexing), to make downloading large apps in stages, to help with that too. Very nice!

demonduck
Offline
Joined: 2008-03-14

> Wow, where do I start. I need to get you those
> links. Once you read that it will all be very
> clear.
>
> https://jdk6.dev.java.net/deployment_advice.html
> https://jdk6.dev.java.net/testDT.html
>
> Did you say that you read the Deployment Advice? If
> so then you should already have your answer.
>
> Now, even the smallest Applet can take advantage of
> the deployJava.js script. What you get out of that
> is, a comprehensive browser check and comprehensive
> JRE check. This comprehensive check is exactly what
> has been missing on 90% of the web pages out there
> and the source of many end-users' angst over Java.
> Just one example, in the past, devs had to go get
> the special html code to put the download Java
> button on their web page and then figure out the
> magic JavaScript that detected whether or not Java
> and the right version of Java was installed, and it
> never worked in all the browsers! No longer
> necessary, the JavaScript does all of that now.
>
> Download size now-a-days is much less of an issue
> unless YOU created something really big. J6u10 (or
> is it already in J6?) adds some features (e.g. JAR
> Indexing), to make downloading large apps in stages,
> to help with that too. Very nice!

I read them and still don't see the advantage.

If the JRE auto updates itself to the latest version and the pluginNG only runs the latest version of Java -- what do you gain by specifying a lower limit to the installed Java?

And deployJava.js *ONLY* detects IE; Netscape Family and Safari. So what about the other browsers? And what happens if it disagrees with the browser running it. Does the whole process of downloading the applet stop until IE,FF or Safari are installed.

What's the gain?