Skip to main content

Download-on-the-fly JRE

27 replies [Last post]
cowwoc
Offline
Joined: 2003-08-24
Points: 0

Hi,

I have posted this idea elsewhere but I think it deserves its own heading so people can comment on it.

This is a feature only Sun can provide, for technical and legal reasons, and although Tiger is a very mature product, I believe there remains one giant hole we need to plug in Mustang: JVM installation.

I am a strong believer in Java Webstart. The problem, though, is that the majority of the world's users use dial-up connections to the internet and a 2MB download translates into around 10 mins for them. There is absolutely no way for me, as a businessman, to get my product out to customers if they have to download anything over 2MB. Period. There is nothing I can do to fix this problem, period. Only Sun can (and should) help.

Mustang should combine the power of Java Webstart and PACK200 to provide a new sort of JRE installer. Here is the user-experience I am asking for:

1) User doesn't have Java or Java Webstart installed on their machine. He goes to my website, clicks on a Java Webstart link.
2) "The application you have selected requires Java Webstart in order to run. May I install it?"
3) User selects "YES"
4) Browser downloads a <2MB package that runs automatically, installs the JVM and launches Java Webstart.
5) Java Webstart downloads my application and runs it.

The key here is providing end-users with a "download-on-the-fly JRE". That is, ship Java Webstart with the absolute minimum dependencies. If it must be a native installer, so be it. This new version of Java Webstart would be smart enough so that if my application tries using a JRE core class/package that has not been downloaded yet, it'll go to Sun's server and download it automatically. As time passes, the user will get more and more classes installed on their machine and more applications will run out-of-the-box without having to download any JRE classes.

To me, this feature is the difference between life and death of my product. I also believe it will influence the future of millions of Java developers and will allow Java to enter the desktop domain. What do you think?

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
Points: 0

Javakiddy,

The rate at which dial-up users are converting to high-speed is still very slow. Ten years into the future this problem will still be relevant. I know it's hard to digest, but not everyone lives in a highly-computerized society. It's excessively expensive to get high-speed in some countries and so almost no one does it.

Gili

javakiddy
Offline
Joined: 2004-01-23
Points: 0

Yes I am fully aware of that situation. The problem is the proposed solution doesn't actually solve the problem for dial-up users. Instead of getting rid of a big pain, you've simply converted it into lots and lots of medium sized pains.

You compare Java to the Flash plugin - yet fail to notice that Flash is a one-off installation. If doesn't continually pester the user to download extra sections each time a movie is played - if it did then it wouldn't have gotten 9% of the desktop, let alone 90%!

To be honest, the way things are going less and less people will need to download the JRE anyway, so the suggested solution is only useful for a small band of people who:
(a) Didn't have a JRE already pre-installed on their PC.
(b) Are still stuck with dial-up.
(c) Don't have a CD-ROM/Zip drive, or can't get ahold of the JRE via CD-ROM from a friend, or as provided with a magazine or book.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

> Yes I am fully aware of that situation. The problem
> is the proposed solution doesn't actually solve the
> problem for dial-up users. Instead of getting rid of
> a big pain, you've simply converted it into lots and
> lots of medium sized pains.
>
> You compare Java to the Flash plugin - yet fail to
> notice that Flash is a one-off installation. If
> doesn't continually pester the user to download extra
> sections each time a movie is played - if it did then
> it wouldn't have gotten 9% of the desktop, let alone
> 90%!
>
> To be honest, the way things are going less and less
> people will need to download the JRE anyway, so the
> suggested solution is only useful for a small band of
> people who:
> (a) Didn't have a JRE already pre-installed on their
> PC.
> (b) Are still stuck with dial-up.
> (c) Don't have a CD-ROM/Zip drive, or can't get ahold
> of the JRE via CD-ROM from a friend, or as provided
> with a magazine or book.

My experience has been that the *vast majority* of users do not have the JRE installed. Also, the number of them that have installed a JRE from a CD is ... zero as far as I know. The bottom line for me is that this *is* going to be an issue for a good while. The majority of the people in the world don't have the JRE installed. They use a dial-up connection. And my experience has been that almost no one gets the JRE by CD. The user experience is... browse the web ... hey cool application! ... download and install ... uninstall if I don't like it. That's it. As such, I am targeting dial-up users that install software they download from internet.

Again, if your customer requirements differ from mine that is alright. I'm only describing my customer requirements.

Gili

javakiddy
Offline
Joined: 2004-01-23
Points: 0

I don't really intend to turn this into a big fight. It's not that we disagree on the problem, it's just that we differ on the solution.

Although WebStart can function in many different circumstances, it makes most sense when used in a broadband/'always on' environment. I do not believe you can solve the problems of 'low bandwidth/limited connection' users by tweaking a technology pitched mainly at 'high bandwidth/always on' users.

(Yes I KNOW WebStart can be used on dial-up modem... Unix can be used on a Commodore 64, but that doesn't make it the ideal! :-)

I genuinely believe that fragmentation of the JRE into a multi-part download is inherently prone to errors, and will result in problems which will taint Java's image. I believe if Java makes the user wait serveral minutes each time they install new desktop applications while it goes off and gets more bits of itself, this too will taint Java's image, and will push people away from using Java on the desktop.

Ultimately it comes down to this: I think there are better ways to solve this problem. I think the solution lies in pushing for even more pre-installation on desktop PCs and by making sure Java is easily available on CD-ROM (for example, by promotional efforts to get it included on magazine coverdisks and the like). I notice that products like Mozilla FireFox and many Linux distributions are already successfully promoted this way...

One final point, and then I'll leave this topic to rest: You talk about reaching out to address the needs of poor countries who do not have widespread broadband yet. The fact is that any country rich enough to have a reliable phone network good enough to actually make your plan worthwile is likely to move to broadband within the next few years anyway. For the *truly* poor countries around the world, who are so far away from broadband that they don't even have a reliable telephone network, your plan is next to useless.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

How does one explain that the majority of European users are dial-up users? Broadband adoption "anytime now" has been oversold for years.

On the topic of tarnishing Java's image, I am as determined as you are to make sure this does not happen.

If done right, I honestly don't believe this will tarnish Java's image at all. If anything, it'll expose more users to it to strip away its reputation of being bloated (13MB down to 2MB).

Secondly, Sun and Mozilla are inheritly different organizations. The former is a cash-strapped corporation and the latter is a grass-root movement. The only reason Firefox is being installed on machines left and right is because it is popular, provides a better user experience than its competitors, and is a 4.5 MB download. If the JRE was a 4.5 MB download, as opposed to 13MB, I guess we could discuss this further, but it is not :) Furthermore, the days of Java being cool are over. This is no longer a matter of marketing but rather providing the end-user a better experience or usability.

"Build it and they will come"

Again, I trust that Sun knows better than you or I as to how to improve Java deployment without tarnishing Java's image. I only ask that in so doing they consider suggestions you and I have brought up. I specifically request they consider my requirements of targeting dial-up desktop users. That's it, that's all :)

Gili

monika_krug
Offline
Joined: 2004-10-14
Points: 0

> nor is there a need to prompt
> the user for permission to download more parts of the
> JVM. The JVM detects missing classes at runtime (it
> already does this) and downloads those missing
> components on-the-fly.

But you are talking about modem users. They are typically not connected to the internet while they use your application.

Monika.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

> > nor is there a need to prompt
> > the user for permission to download more parts of
> the
> > JVM. The JVM detects missing classes at runtime
> (it
> > already does this) and downloads those missing
> > components on-the-fly.
>
> But you are talking about modem users. They are
> typically not connected to the internet while they
> use your application.

They will be connected the first time they download and run the application. JWS can run from the cached version from then on.

Gili

draccagni
Offline
Joined: 2003-06-16
Points: 0

I completely agree with you. All, please don't focus your attention on installation package size : in any case we need a way to do it !

javakiddy
Offline
Joined: 2004-01-23
Points: 0

With increasing acceptance of broadband, will Java's download size still be an issue a few years from now?

With increasing network bandwidth, will Java's download size still be an issue a few years from now?

With more and more desktop computers coming with Java pre-installed, will Java's download size still be an issue a few years from now?

While I support some kind of dynamic and automatic 'discovery/installation/management' mechanism for third party packages, this whole debate about the carving up of the JRE does strike me as a very drastic (and therefore error prone) solution to a very short term problem.

sat1196
Offline
Joined: 2003-11-08
Points: 0

> With increasing network bandwidth, will Java's
> download size still be an issue a few years from
> now?

I think the size of the vm is growing exponentially with each new version, so it might still be a problem with mustang, dolphin...

But the smart idea here is to use the pack200 utility. The vm isntaller could have the jar files (rt.jar, etc) in a packed format and then unpack it after download. I used pack200 on rt.jar of the 1.4 vm and it went from 21.6M to 2.9M.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

sat1196,

The JRE installers have always been using PACK200. That is, PACK200 has been used to pack JREs for a long time but only recently Sun has made this compression algorithm available to the public in the core API. In a nutshell: JRE installers will not get smaller by using PACK200 since they already use it.

Gili

asjf
Offline
Joined: 2003-06-10
Points: 0

this is possibly the last chance of getting Java clients on the desktop?

the mechanism should do something like

--- from site maintained by Sun or the community
1) core libraries (maybe not gui stuff?)
2) subdivide j2se libraries into bite size pieces
3) common libraries (like maven's ibiblio site) - eg jakarta jars etc..
--- from application providers site
4) users jars

http://forum.java.sun.com/thread.jsp?forum=32&thread=505825

http://forum.java.sun.com/thread.jsp?forum=31&thread=409892

i guess you might be able to do this via a BiteSizeOnlineClassLoader that got things on demand?

webstart has been improving but its still not quite there because it doesn't do exactly as cowwoc (and many others) have suggested

asjf
Offline
Joined: 2003-06-10
Points: 0

> this is possibly the last chance of getting Java clients on the desktop?

oops, should explain more..

since Java can't be assumed to be on a customers desktop, and [b]even if it is[/b] then you don't know

A) where it is
B) what version it is
C) if its been corrupted by manually uninstalling etc..

this also means that start-up time can be a problem since you may be loading a separate JRE to one already in the file system cache

.NET has a big advantage in the medium term in this respect?

i guess there might be a bootstrap problem with having a link in a webpage that does this, unless whoever implements this mechanism provides native binaries that can be downloaded and run?

asjf
Offline
Joined: 2003-06-10
Points: 0

this also came up on one of the threads on the www.java.net page - i think maybe during a Swing discussion and a good number of people just said "yes, obviously, some central competent group just needs to sit down and sort it conceptually, and then do it"

paulrivers
Offline
Joined: 2004-03-04
Points: 0

If they did do this, you would need some way of specifying which optional parts of the jvm you end-user would need, so they wouldn't have to click on the link, click on the prompt, download the app and jvm, then download more of the jvm again...

What I would really like (and I'm sure will never happen) is the ability to bundle just the parts of the jvm that application needs with my application, but have be a app-specific jvm (the jvm isn't installed on the end-users computer, it's only intended for my app). This has several advantages for me:

1. Smaller download size
2. No need to have administrative privileges to install my program
3. When you uninstall my program, everything is uninstalled - there's not an extra jvm sitting on the hard drive, taking up space.
4. No need to confuse the user by asking them if they want to install "something else" (the jvm) in addition to my app.

I already bundle a private jvm with my application, (for reasons 2, 3, and 4 above). This would just make the download smaller.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

I really don't get what you're talking about here. There is absolutely no need for the end-user or developer to specify which parts of the JVM the application will need; nor is there a need to prompt the user for permission to download more parts of the JVM. The JVM detects missing classes at runtime (it already does this) and downloads those missing components on-the-fly. There is no need to prompt the user of anything since all components will be signed by a trusted entity (Sun) and download/installation will take place automatically.

While it might seem more beneficial to you in the short term to bundle a private JRE with every application you publish, in the long run it is far more beneficial to you, the end-user, and other developers if there was a single download-on-demand JRE installed on the user's machine. If the user happens to run other Java applications on his system, your application benefits in that the user will have to download less components before your application will run. This translates into a smaller download for your users and "that is a good thing" (tm).

Finally, the size difference between a private JVM specifically for your app versus a download-on-demand JVM, would be so small it isn't even worth mentioning. We're talking about an order of 100k here, not megabytes. As for customized private JVMs; people have been asking for them for years now and Sun will not allow it. I might add that I understand why their point of view and a download-on-the-fly JRE is a far better solution.

Gili

quintesse
Offline
Joined: 2003-08-27
Points: 0

> As for customized private JVMs;
> people have been asking for them for years now and
> Sun will not allow it.

Although a JRE that is partitioned into smaller parts comes very close to what a lot of those wanted anyway, isn't it?

It seems that if I want to publish a small application and want only to include the barest minimum of the JRE I could do so with this new system, couldn't I?

Just add the parts of the JRE you need and leave the others in the "download on first use" list.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

Correct. You get the best of both worlds!

cowwoc
Offline
Joined: 2003-08-24
Points: 0

I should add that I've done some feasability studies on my end, and it *highly* likely that we can ship this sort of installer in under 2MB.

Just *imagine* the possibilities if Java was a smaller download than the Flash plugin. Today, Flash is installed on >90% of all desktop machines.

jwenting
Offline
Joined: 2003-12-02
Points: 0

bad idea. Maybe if that customer has only a single application he'll ever run it'll work but how will you explain it to him if he has to install the JVM AGAIN for the next application and again for the one after that because he needs different parts of it every time?

The user thinks he has installed the JVM so now he can run Java programs. But he can't because he only installed the little parts of it your application uses.

It would only add more confusion to people already confused that they need to install a third party application in order to run yours.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

You misunderstand. The user wouldn't have to install the JVM again for the next application. There is still one JVM shared by all the applications. The point is that it downloads classes on-the-fly instead of being static.

There will still be special cases where users will want to download the offline JRE installer and install everything in one shot, but for dial-up users (and frankly most desktop users that I know) a download-on-the-fly JRE is preferable.

javakiddy
Offline
Joined: 2004-01-23
Points: 0

What it comes down to is this: is it better to download a single large application and get the whole thing over and done with in one go, or is it better to download bits at a time, and spread the load?

Picture this from an end user point of view. He downloads a Java application, the documentation for which says he needs a JRE. So he trundles off to java.sun.com and downloads Java. All is fine, and the user thinks Java is the bee's knees! (Never understood what that means?!?!! Anyway...)

Next day he downloads a second Java app. Eager to try out his new find, once again he it told he can't run the software straight away. He must wait for more of Java to download. Impatiently he waits while more sections of the JRE are loaded and installed - and finally he can try his new software. He still thinks Java is quite nice, though.

The next day he downloads yet another application. Keen to try it out, he is once again greeted by a dialog: "Please wait while I download the [whatever] package to your computer... Loading... loading... loading... installing... please wait... installing...". Finally he gets to use the software. He now thinks Java is okay!

The next day he gets yet another Java application. Once again he tries to run it. "Please wait... downloading... please wait.... installing... please wait...". He now is starting to wonder whether Java is all its cracked up to be...!

UNDERSTAND THIS: Acceptance of software products is based heavily on how hassle-free they appear. And the moment at which expectations are at their highest is when the users has just 'opened the shrink-wrap' (so to speak) and is trying a new application for the very first time. It's kind of like a "new application buzz" that we all get. Excitement and apprehension. Will it work? Won't it work? Is it the best thing since sliced bread, or the worst thing since the MS-Word Paperclip? THIS IS THE WORST TIME TO FRUSTRATE THE USER WITH EXTRA DOWNLOADS AND INSTALLATIONS.

My view is that the solution to the problem is to push for Java to be installed as standard on as wide a range of equipment as possible. It its on your machine from the moment you first switch it on, then you don't need to worry so much about download size.

A couple of technical complications (while not unsolvable, they add complexity, and therefore are potential points of failure) :

1) We are assuming all users are using a single brand of JVM. What happens if the user has installed the core JRE from IBM? Does it attempt to load AWT packages from sun.com, or ibm.com, or somewhere else? Will applications document where to find these extras, or will the JVM know instinctively where to find them - and if so, how?. Will the AWT 'bundle' from Sun work with the IBM core JRE? (Presumably they both contain native code.)

2) How do we upgrade from an old JRE to a new one? Presumably everything will have to be versioned, and the installer will have to know when the installed component is not sufficient and get the new one? What happens when components don't fall neatly over the footprint of their ancestors? For example if multiple bundles are combined into one, or an existing bundle grows so big that it is split in two for future versions? Can we keep track of all the dependencies, and ensure the JVM *always* knows what's what? What happens when the system breaks down and it gets confused - do we just suggest users wipe the whole of Java and reinstall from scratch? (Like many PC Helplines, who simply chant the mantra "Have you re-installed Windows?" to even the most trivial of inquiries.)

(Btw: I spellchecked the above using OpenOffice.org 1.1.1, and its top ranked suggestion for "sun.com" was "communist" ... Hmmmm! :-o )

quintesse
Offline
Joined: 2003-08-27
Points: 0

Personally I think that if they were all very small downloads the user wouldn't notice anything. Especially if it's done as invisibly as installing flash is done (at least in IE on windows).

And if you ever have a program that uses so many packages that the download comes really noticable the situation is no worse than it is now.

javakiddy
Offline
Joined: 2004-01-23
Points: 0

The only way to get the sizes down to a point where they aren't really noticable is to carve Java up into dozens of tiny packages. That level of fragmentation is unmanagable.

If we'd dealing with dial-up users here (as has been mentioned, given that boardband users can get the whole JRE without any pain) then you realistically have to get chunks smaller than 1Mb - better still, smaller than 100k! And that ignores the inconvenience of waiting for the modem to dial, connect and handshake. (Surprisingly, most dial-up users don't sit with their machines 'always on', running up phone bills.) Indeed fragmentation just makes their Java experience even worse - they download and install a Java application, only to be told they have to dial-up again to fetch bits of the JRE when they try to run it!!

cowwoc
Offline
Joined: 2003-08-24
Points: 0

Argh!

You guys drive me crazy...

First of all, worse case scenerio the user would have to download the entire JRE in parts.

Most common-place usage scenerio: user only needs to download 1MB of JRE instead of a whopping 12MB! I am guessing all you people use high-speech connections and don't *really* understand the pain a 12MB download translates to.

As for "the user will keep on getting prompted to download more parts of the JRE": you don't prompt anyone for anything. This is equivilent to using a Java Webstart application that gets updated one day. Obviously the user will have to wait while you download the new version that just came out, but that's normal. You don't prompt the user, you simply download the update and away you go (run like normal). This download time would be *way* smaller than downloading the entire JRE to begin with.

Again, if you were a dial-up user you'd know this: when faced between "download 12MB now" or "download JRE updates every couple of days" most dial-up users will pick the latter because a 12MB download scares them all away and forget about "user convience" when you have no users because they all ran away.

Lastly, "library fragmentation": we don't need to manually split up the library. Users run an application. If the application uses a class that has not been downloaded yet, Java Webstart downloads the entire package that class is in. Automated splitting of library, no hassle, no headache.

Gili

javakiddy
Offline
Joined: 2004-01-23
Points: 0

[b]I am guessing all you people use high-speech connections and don't *really* understand the pain a 12MB download translates to.[/b]

You are incorrect. I regularly have to deal with machines which are only connected via dial-up.

[b]As for "the user will keep on getting prompted to download more parts of the JRE": you don't prompt anyone for anything. [/b]

That's even worse. So I start up my brand new application and it just appears to hang.

[b]This is equivilent to using a Java Webstart application that gets updated one day. [/b]

WebStart applications are not really aimed at dial-up based computers. Although they obviously can be used by dial-up users, WS is really designed for an always-on environment. After all, who wants to fire up their modem just to open a text editor?

[b]You don't prompt the user, you simply download the update and away you go (run like normal). This download time would be *way* smaller than downloading the entire JRE to begin with.[/b]

This is the point at which *I* seriously doubt whether *you* actually use dial-up on a regular basis. Nothing on dial-up is ever 'simply downloaded'. For a start it is highly likely there will be no connection when a Java desktop application is actually first run. So to 'simply download' the necessary components the computer has to prompt the user to dial-up. (I've no doubt it could do this automatically, but in this age of viruses, spyware and dialers, it is politically better to ask the user!)

Then they have to wait... wait... wait... while the module is fetched and installed. (A 1Mb file will probably take a few minutes to get.)

At this point the user is thinking "Why do I keep downloading Java deskop apps? Why don't I just download the native .EXE version and be done with it?" :-)

[b]Again, if you were a dial-up user you'd know this: when faced between "download 12MB now" or "download JRE updates every couple of days" most dial-up users will pick the latter[/b]

Do you have any evidence of that, because one of the dial-up machines I have to use has an Anti-virus package on it which will silently attempt to update itself when there is a connection, and its a bl**dy pain in the a**e, bringing limited bandwidth down to a mere trickle.

Surely most users of dial-up computers would rather have their JRE pre-installed, or available for free on a magazine coverdisk? I think a far better solution to this problem is to push to have Java pre-installed on as many PC's as possible, and make user new JRE's get maximum coverage on magazine coverdisks, etc.

cowwoc
Offline
Joined: 2003-08-24
Points: 0

[b]That's even worse. So I start up my brand new application and it just appears to hang.[/b]

What?! That is nonsense :) Look... right now if you start up JWS and the application has been updated on the server it displays a progress bar on downloading updates. This would be no different; you'd display a progress bar on download dependencies, whether they are application libraries or core libraries.

[b]WebStart applications are not really aimed at dial-up
based computers. Although they obviously can be used
by dial-up users, WS is really designed for an
always-on environment. After all, who wants to fire
up their modem just to open a text editor?[/b]

Again this is nonsense. JWS can be run without a network connection. If no net connection is present and you run the application it simply uses the cached version. If you happen to install a new application from a CD, you should be able to get the JDK off there as well so that's no problem. If, on the other hand, you went off and downloaded a new application which required new core library components, it'll use the existing connection to download those dependencies. No problem here.

[b]This is the point at which *I* seriously doubt
whether *you* actually use dial-up on a regular
basis. Nothing on dial-up is ever 'simply
downloaded'. For a start it is highly likely there
will be no connection when a Java desktop application
is actually first run. So to 'simply download' the
necessary components the computer has to prompt the
user to dial-up. (I've no doubt it could do this
automatically, but in this age of viruses, spyware
and dialers, it is politically better to ask the
user!)

Then they have to wait... wait... wait... while the
module is fetched and installed. (A 1Mb file will
probably take a few minutes to get.)

At this point the user is thinking "Why do I keep
downloading Java deskop apps? Why don't I just
download the native .EXE version and be done with
it?" :-) [/b]

The only way the above case could take place is if the user gets a new JWS application from CD. If this is already the case, you give him the entire JDK. I'm only discussing the case when users get an application from the network, hence they *do* have a connection to be able to download new core libraries.

[b]Do you have any evidence of that, because one of the
dial-up machines I have to use has an Anti-virus
package on it which will silently attempt to update
itself when there is a connection, and its a bl**dy
pain in the a**e, bringing limited bandwidth down to
a mere trickle.[/b]

JWS is not silent. It displays a progress bar and you can cancel the download if you wish. This is not the same as your silent anti-virus update.

[b]Surely most users of dial-up computers would rather
have their JRE pre-installed, or available for free
on a magazine coverdisk? I think a far better
solution to this problem is to push to have Java
pre-installed on as many PC's as possible, and make
user new JRE's get maximum coverage on magazine
coverdisks, etc.[/b]

The two cases can coexist. Indeed, I am not asking for Sun to abolish the idea of distributing the full JRE. I am simply saying we should have a download-on-the-fly JRE for users that *do* want to download it from the web instead of using a CD version. If you get the entire JRE off a CD that's just fine.

My personal experience has been that *my* customers don't have a JRE installed on their machine, I cannot ship them one by CD and they are likely to sample my application off internet. They want to try before they buy and in such a case shipping them a CD is not an option. That's just been my experience (I am in no way trying to poo poo over your experiences. It sounds to me like your customers have different requirements than mine.)

Gili