You guys made a factual error: the JRE install is 7MB, not 15MB (so long as you use the "online installer").
Now on to my own rant:
- No, "most operating systems" do not come preinstalled with Java especially when "most" don't matter: Windows does.
- Even if Windows came preinstalled with JRE 1.4 today, most people would want 1.5. Even if it came preinstalled with 1.5, most people would want 1.6 tomorrow. The point is: the JRE is a moving target with new "killer features" coming out every year or so (even in update releases) and it isn't enough to rely on the OS to bundle what you want, it should be easier to install/update the JRE in the first place.
I don't come to you with any sort of proof that people abandon downloading the JRE due to size, but to me it seems quite logical:
90%+ of computer users have Flash preinstalled
The Flash installer is 2MB in size
Downloading 7MB for a dial-up user takes approximately 40 minutes. Downloading 2MB takes approximately 10 minutes. I don't know about you, but there is no way in hell I would ever wait 40 mins to be able to get an application to work.
This is especially more true given the nature of Java desktop applications. Sometimes all you want to do is download a Java app which does something really small and simple ... how do you justify downloading 7MB for that? Again, think with the brain of a dial-up user, not a broadband one.
I am strongly advocating to transform the JRE into a compact deployment framework: include as little as possible for it to be able to install-on-demand optional components such as JDBC, CORBA, maybe even Java2D. Point is, a good 50% of J2SE could become optional components. Yes, this won't take much off the J2SE footprint but going down from 7MB to 3MB is a very big deal for dial-up users! And they make up the majority of the users in today's market.
3MB is a realistic figure because from personal experience I've used Proguard (http://proguard.sourceforge.net/) to strip down the JRE to the bare minimum required to run my desktop application.
So in conclusion: J2SE should become "Webstart on wheels" :) It should install J2SE optional components on demand and the majority of today's J2SE components should become optional.
This will take a lot of work (especially mapping the dependencies of J2SE native code) but I believe it is necessary for Java to enter the desktop world.
Alternatively... We could bundle J2SE with all major operating systems (especially Windows) and downloading upgrades using the online J2SE installer actually only downloads patches/diffs so the download is (supposidly) way less than 7MB. This approach is feasiable as well for dial-up users, and might be easier for Sun.
Breaking up the J2SE would have the added benefit that individual modules could progress at a different release rate, and you could open-source them at java.net like other optional J2SE components. That sounds like a pretty big deal to me . . . which is why I am still opting for the first option.
> - No, "most operating systems" do not come preinstalled
> with Java especially when "most" don't matter: Windows does.
I bought a Windows XP laptop a year ago, and it had JRE 1.4 preinstalled. Maybe that is for some vendors only.
Java vs Flash seems like apples vs oranges. A vector graphics renderer with simple GUI scripting vs a full featured language.
> Again, think with the brain of a dial-up user, not a broadband one.
It's been several years since I used dialup regularly. I'm not sure I would have been a great fan of a programming language that occasionally wanted to "call home" - connect charges and unpredictable pauses...
> This is especially more true given the nature of Java desktop
> applications. Sometimes all you want to do is download a Java app
> which does something really small and simple
Very true. So we have identified a potential customer for a small JRE:
- Wants to run small applications (and only small applications; if he uses even one real application, JRE size becomes less important, and he will need more and more of the full functionality anyway)
- and the small applications he runs need the same parts of the JRE (if one app uses Swing, another XML, another JDBC, there goes the ballgame)
- and has dial-up (slightly less than 50% of US users, btw)
- and is willing to download for 10 minutes (but not 40 minutes) (timings assume 33kbit modem, right?)
- and doesn't mind the programming language calling home occasionally
- and can connect enough of the time (no connection = no downloads of components = broken programs)
- and does not have an operating system that comes with Java, and can't get it elsewhere.
Do you have a lot of customers/users who say they will not download 7 MB but would download 2 MB? Do you have some numbers - percentage of users, ...? Real researched facts could go a great way towards showing how serious a problem this is. Just to show The Powers That Be that the "&& statement" list above doesn't result in a relatively small number in reality.
> This will take a lot of work (especially mapping the dependencies of
> J2SE native code) but I believe it is necessary for Java to enter the
> desktop world.
One problem is Class.forName(). Static analysis can't tell what classes will be needed. Quick: will the MySQL JDBC driver need an XML parser?
An even better solution: ship Java with operating systems. Put it on application CDs (like graphics drivers come with games and everything comes with Adobe Acrobat Reader (Reader = 26.8 MB download, heh)).
> Breaking up the J2SE would have the added benefit that individual
> modules could progress at a different release rate
I wonder if this is a benefit or a nightmare. Will Swing 1.8.107 work with HashMap 6.2005-07-08.017 and Xerxes b-433-2/7-beta2... Combinatorial explosion of versions to test...
Hmm, you wouldn't need the software to dialup regularly as it discovers it needs more parts. The first time you download or run the software it could download all required components at once. This should be configurable as it currently is in Webstart, which allows either eager or lazy dependency fetching. So anyway, this isn't an issue.
> problem is Class.forName(). Static analysis can't tell what classes will be needed.
Absolutely, I agree with you 100%. It is going to take some serious work to map some of the Class.forName() dependencies (ProGuard actually catches the majority of them automatically) but this is something you'd have to do once. Once you've got it configured, if any changes occur in the code, adjusting your configuration file is trivial (it's easy to maintain). Anyway, I already built such a configuration file for the JRE (which is huge!). I'm one person. If I could do it, Sun sure as heck can too! I'll even donate my configuration :)
> I wonder if this is a benefit or a nightmare. Will Swing 1.8.107 work with HashMap 6.2005-07-08.017 and Xerxes b-433-2/7-beta2... Combinatorial explosion of versions to test...
I really don't see what the big deal is. So many people use this FUD to discourage breaking up the JRE... You know what? Dom4j conditionally depends on a whole slew of different XML parsers and there are many other 3rd party libraries which very complex dependencies and they get by just fine. If they can do it with no big headache, why would the JRE be any different? It really isn't that big a deal!
This headache, big or small, shouldn't be on Sun's back. It should be on the back of whomever actually ends up maintaining the various packages and if we open-source some of these on java.net in the future, it'll be up to those teams to do good testing. Again, Dom4j does it just fine. I trust others to do a good job too.
> [i]So, Java is moving in opposite directions of[/i]
> [i]where the developers want it. We want[/i]
> [i]better/faster/lighter Java.[/i]
By "the developers", do you mean "applet developers who use Java as a replacement for vector graphics displayer"?
Please do not pretend to be speaking for all developers.
I do most of my Java work in enterprise server side programming, so splitting up rt.jar into separate pieces would help me exactly none at all.
Even with my applets I have never heard a customer say "I won't download 15 MB, but I would download 5 MB". What percentage of your users really say that?
Don't most operating systems come with preinstalled Java nowadays?
> I do most of my Java work in enterprise server side
> programming, so splitting up rt.jar into separate
> pieces would help me exactly none at all.
You use a jre? or sdk? or even J2EE?
I listed my suggestions, to remove the cruft or deprecated. What is your suggestion for people that write applications, how would you get JRE smaller to decrease the download time?
> You use a jre? or sdk? or even J2EE?
On "my" machines JDK, customers who use my applets use any one of those they want.
> remove the cruft or deprecated.
Are there enough deprecated classes and methods to make download times significantly smaller? If the average download becomes, say, two percent faster, is it worth the work and the risk of breaking code? Is the amount of deprecated stuff a real problem for a significant number of JRE downloaders? Sure deprecated stuff should be phased out; is it urgent?
> how would you get JRE smaller to decrease the download time?
First I would try to find out whether the size of the JRE really is a problem for a significant number of people. And would those people be satisfied with a 5 MB download, or would even that be a show stopper for them (i.e. would all the work of reducing JRE size and perhaps adding incremental loading complexity go to waste).
I have never heard a customer say "I won't download 15 MB, but I would download 5 MB". What percentage of your users really say that?
I'm not asking that question to make smalltalk; really, how big a problem is it for you and how many of your users would be satisfied with the 4-5 MB goal you suggest? Have you done a user survey or something?
> really, how big a problem is it for you and how many
> of your users would be satisfied with the 4-5 MB goal
> you suggest? Have you done a user survey or
The users of my application are aborting using the application as it needs a JRE download.
W/o java users, no java apps, no java developers.
When I write an application in C#, users have to download 0.
When I see this kind of bold statements I really start thinking of the reasons for the original post.
Did the original post try to solve a problem ?
Was it spreading FUD ?
For what I understand the post says:
Java is big -> therefore -> people do not use it.
As a further claim
.NET does not need downloading -> therefore -> people will use it.
To me this is just professional FUD.
A positive approach would be:
How can we campaign to have Java in every desktop in the same way as Flash is available ?
If one install the JDK and the JRE (to be able to use java web start) is there any special reason why there should be two JVM installed ? (One under the JDK and one under the JRE)
Would it be reasonable if when one installs a JDK the JRE is also installed ?
In case one installs a JDK compatible with a given JRE, would it be possible for the JDK to use the JRE that is already installed ?
Having said this, it appears that the upcoming Java has a core of just 7Mb, quite small for today broadband.
Your use of this web site or any of its content or software indicates your agreement to be bound by these Terms of Participation.
Copyright © 2014, Oracle and/or its affiliates. All rights reserved. Oracle and Java are registered trademarks of Oracle and/or its affiliates. Other names may be trademarks of their respective owners.