Idea to decrease download sizes for users

General Discussions
#1

Hi everyone.

I don’t want my game to be larger then it has to be. A big factor in the size of Java programs is the JRE, which I’ve checked for java 1.5 is 15 megs for a windows installation which is probably too big for someone on a 56k.

So my idea is this, instead of downloading all the classes for the JRE from sun, instead download a file from sun that acts as a cache for classes so you only download the classes you need to run your program. So if my program uses the math class that class is downloaded from a repository on suns server and stored in a global cache on your computer, when another java program requests that class (import java.util.Math) java can find that class through the cache and this saves having to download a bunch of classes your program doesn’t need… Of course if your program downloads a class that requires another class then both are downloaded in the cache… Well this is just a idea, so take it with a grain of salt and please tell me your opinion…

#2

It’s been thought of already - might even be in as an RFE “modularize the JRE” or something. The granularity won’t work well at the class level as the TCP/IP and HTTP overhead for downloading individual classes would cripple it and probably be a versioning nightmare. It would probably work at the JAR level.

One critical issue is that AWT and Swing are kind of inherent to the JRE install and they’re two of the largest bits.

What would solve the problem completely is just allowing us to split the JRE ourselves :slight_smile: But as they’re not going to back down on that might I suggest you do it anyway and then tidy the evidence under the carpet with Molebox.

Cas :slight_smile:

#3

Thanks for the reply.

You mentioned problems with versioning, why not just have a different cache for each version of a jre? or better yet replace only the classes that have gone up in a version number. If we could decrease the size of the jre that would be a huge selling point for games. BTW does sun have a problem with people who want to compile java into different exe files? is that legal?

#4

Big Problem is this:


Class c = Class.forName(<a String>);

Now imagine you can set that dynamically from the user side. Then this class might not exist, even if it is in the standart API and the user would get a not understandable error message.

#5

All you need to ship with the JRE is a manifest of “known class” locations.

Cas :slight_smile:

#6

Its been explored repeatedly at Sun.

If you wan’t to see the biggest roadblock, take a look at the size of the native DLLs.

Now go look at the sourec code for those DLLs under WIn32…

JK

#7

There’s no versioning scheme worth mentioning built-in to java at the moment, and versioning systems are fairly complex beasts to get right and good and efficient and flexible etc - so they’d also need to get a complete versioining system up and running, and that makes anything to do with versioning a great big kettle of worms.

At least, AFAICS :P.

#8

I really hope sun looks into it more because imho it’s a big problem in java, especially for general purpose applications… Most programs made in java are small anyway so it seems like a waste to have to download 1000+ classes that have nothing to do with your program… It also contributes to the idea that java is slow because there might be a more efficient jre available but the user doesnt’ want to download it because it’s more then 10 megs…

#9

Was complpetely explored at Sun over two years ago.

Not doable with the current codebase.

Period.

For reasons pointed at above.

#10

[quote=“SpiritWolf,post:1,topic:24350”]
It’s been a while since we’ve visited this issue. Is there a significant percentage of gamers still left with 56k? I mean a significant group that would actually bother to download games in the first place that don’t already have high-speed connections? Do those people even have a PC that is up-to-date enough to run your game?

Just wondering if someone has some updated stats that might help put things in perspective. A while ago Ithink the number of people on high-speed was around 50%, and that wasn’t broken down in a way that we could tell the distribution of gamers, particularly those that downloaded games or played online games.

Around here cable modems are now up to 7Mb/s for $45/month (That’s Canadian $, so less than $40/month USD). On the typical 3Mb/s DSL/Cable connection a full download of the latest JDK (not JRE, the significantly larger JDK) takes less than 3 minutes. So for high-speed users the JRE size is certainly not an issue. The question remains, how much of the market are we losing if 56k users won’t bother with the download?

#11

Even if this dynamic class loading over HTTP did work without any bugs, 56Kers would still be next to hopeless because they would need to dialup to launch an application (at least for the first time when the cache is empty)… especially if the application does dynamic class loading that might need yet another class even after the application itself already exists on the HD… more dialing! If the application happens to be Swing, then they’ll be waiting a while for that to load… ::slight_smile:

The reason Java programs are so small is because there are 1000+ classes… and your program uses more classes than you think. Even by using a JFrame… that JFrame uses Containers, Components, EventListeners, Fonts… the list goes on. If I was 56K, I would rather just downlaod the JRE all at one time than to randomly have some new program lag because some uncached classes needed to be downloaded. Streamed classes would shoot Java’s “slow” rating through the roof (“I had to wait an hour or tetris to load! and it wasn’t even that good!”) :stuck_out_tongue:

#12

Well after hearing all this it seems like it wouldn’t work that well. But that doesn’t mean theres not other ways to cut down on the size of the JRE, couldn’t sun make a mini JRE for video games? Maybe it could be like j2me but bigger?

#13

J2ME is controlled by a process called the JCP.

Each specific platform, such as MIDP, is called a “profile” must be defined through a process called a JSR. It takes time and committment from industry players who commit their people’s time, energy and resources.

In each case, a specification must be agreed to, it must past review of both the community and the executive board that controls the entire process, and then a reference implementation must be created. In aprticualr, along with the refence implementation, somethingcalled a Technology Compatability Kit must also be created. This is a set of tests thatcan be used to validate thrid party implementations.

This all takes time and money. In manycases the TCK in fact takes much more egineeering then the reference implementation itself.

We’ve been down this road. I led JSR134, the Java Game Profile. We had invovlement from game industry academia, from industry leaders, and from major Java players. We got all the way to a profile definition and stalled because noone wanted to foot the bill for the TCK.

Its not like we havent explored all these approaches already. Believe me.

#14

Perhaps worth mentioning that the online form of JRE installation downloads rather less than the offline one. To start with it doesn’t download the Windows Installer unless it has to — the offline installation always has that included.

#15

Best solution is to have the JRE pre-installed and auto-updating on as many PC’s as possible.
AFAIK, Sun already has done a lot of effort in having that done. Does anyone has some up to date stats of how many new PC’s have the JRE pre-installed?

#16

This would appear to be the case of a lumbering overweight software company gettings its knickers in a twist because it can no longer rapidly get products to market. You know that I’ve already achieved the engineering side of it and it was very easy to do. Seeing as the TCK side of it is similarly easy to do - it’s literally a subset of the JRE1.4 TCK - it would appear that Sun haven’t really tried very hard to crack this market.

I don’t really care any more anyway. The best market’s on the Mac, and the Windows problem I’ve solved with cloak and dagger - and that is the best solution available today if you don’t want to deal with broken JREs on users’ machines. Which I don’t.

Cas :slight_smile:

#17

Yep, and what you really want to do is run java in one of the debug modes (-XX:something I can’t remember now) where it prints out the names of each of the classes it’s loading as it loads it.

How many classes do you reckon it takes to run Hello World? People have been surprised :wink: (although IIRC this has now been pulled down to a very small number)

How many to display a single JTree in a single frame?

#18

Well theres the answer then - change the codebase.

Of course this will never happen as Sun doesn’t care about Java on the desktop.

#19

swpalmer’s point is a good one. There is no point solving a problem that does not exist. Do these dial-up users actually want to play your game and are they capable of doing so?

All of the people that I know who would be interesting in playing a game have broadband, and I’m in Australia where broadband penetration is less than that of North America.

I agree it’s also nice to see computers being shipped with Java and auto-update.

Will.

#20

There is a problem but is actually several problems and they affect different industries differently.

At work we rely on customers with broadband to install Java 5.0 and our app is delivered over Webstart. No problems there.

My other business of developing games is buggered by Webstart as there is no way to streamline the deployment process and I rely too heavily on Sun’s very poor track record of dealing with this market. Broadband is not really an issue for me as my games are getting on for 4mb of pure content in the first place; but the problem of broken versions of the JRE would affect me badly. However Webstart is horribly ugly, generally considered to be pernickety, and not at all aimed at game deployment. I’d have to insist on my own Puppygames skin for it, for example. The other problem is that at 15mb it’s a major chore to download even for broadband users. My games are only 2mb bigger with a JRE embedded in them than the pure Java code I ship for the Mac.

Tribal Trouble has circumvented the problem by simply being big enough that bundling an entire JRE with the game wasn’t a big issue. So they don’t really have a problem. They’re getting a retail deal sorted out too and an embedded JVM makes absolute sense in this situation as it’s one less random variable to worry about when the box hits the shelves and can no longer be changed.

If you want the problem solved - give up, Sun are simply not interested in the desktop gaming market. We all know that. Jeff and Chris might make noises about it but we know that they’re virtually powerless to actually make something happen here because Sun have not appointed an executive officer to carve this market (unlike, say, Microsoft, or Sony, who have such an officer).

However giving up on solving the problem does not mean it cannot be completely worked around with great success, which is what I’ve done. Here’s a tip: delete everything from the JRE you don’t want, embed it in your game, and compile the lot in Molebox so you’re not breaking any licensing agreements. It’s cloak-and-dagger but it keeps everyone happy.

Cas :slight_smile: