Java Application Installation is a NIGHTMARE

General Discussions
#41

[quote]Any install that requires an extra step by the customer is one more step that can cause that customer to give up and not run / play that application / game. Installers such as Install4j can make this a minor issue. (So why doesn’t Sun distribute an installer with Java instead of leaving developers to have to search out an install solution?)
[/quote]
Sun’s brilliant marketing at work again. THEY HAVE AN INSTALLER…

It was done as a reference implementation of JSR-38…

http://www.openinstallation.org/

JIFI - it may need work still… but it’s a start. Very much like Install Anywhere actually.

#42

.jax ???

edit:
http://mindprod.com/jgloss/jax.html

JAX
A Jar file with a *.jax instead of *.jar extension. It contains a special entry in the manifest to tell which class file in the jar is the main one. A JAX file can be directly executed, just like a *.exe file with the appropriate associations. In JDK 1.2 you can execute jar files directly.

Uhm… we do have that now with usual jar files, too. And “.jax” isn’t asociated with anything on my machine.

#43

About installint different JDKs in random order, and then default one is not the newest one. Very annoying for developers machine but easy to fix in Win machine, once you know what to do :wink:

Ive fixed reference problems this way:

  • Run Regedit
  • Go to HKEY_LOCAL_MACHINE/SOFTWARE/JavaSoft
  • Edit CurrentVersion value in each folder to point what should be used as a default

“Java Plug-in” and “Java update” don’t have that value, but “Java Development Kit”, “Java Runtime Environment”, “Java Web Start” folders have.

Then c:/Win/system32/java.exe and javaw.exe may be overwritten with the appropriate versions.

  • Copy exes from c:/program files/Java/j2re…/bin folder

Not elegant, but works.

This same regkey contains “Prefs” folder where applications using PreferencesAPI may store values. Another one is in CURRENT_USER tree.

#44

Im have Vampire the Maskerade installed on my hard-disk and it makes use a jvm. The files are in the game root dir:

classes.zip - 8543 kb
javai.dll - 407 Kb

Can bundle a jvm this way, or do we need to obtain permission from Sun first ?

In the case of a java game the only executable needed would be a native win32 program to start the vm and execute the right class.

The advantages of this method is that, in principle, the player only has to unzip the game and run the start executable. No register messing and no installer needed.

In principle the player could also edit an .ini file or run a setup program to point to an external jvm dir. Most players can do this kind of stuff very easly.

Yeah and Andrew thanks for some more free java gaming articles.

#45

[quote]Can bundle a jvm this way, or do we need to obtain permission from Sun first ?
[/quote]
In principle, you need an embedded VM licence to do something like that. In reality, Sun have bigger concerns than punishing a few hobbyist game developers who are just trying to make a few quid. Keep it quiet, and Sun will likely turn a blind eye.

Naturally, no one here would openly condone something like that. :wink:

#46

What if we used another jvm, independent of sun jvm ? Like kaffe for instance or the jvm from ibm. Could we still pack it with the game without having problems with sun license ?

#47

I know this sounds a radical idea, but…why don’t you just ask Sun?

Or, even more radical, just include a full JRE (which has virtually no restrictions), get all the advantages of java, and not have to worry about the problem that sooner or later you’ll find there’s a bug in the version of java you distributed and now you have a massive great expensive pain trying to upgrade all your users.

IMHO if you’re going to use a language, you ought to use it the way it’s meant to be used, because unless you have really pressing reasons otherwise (which you don’t seem to have) then it’s just creating additional work for yourself in the long run.

#48

[quote]What if we used another jvm, independent of sun jvm ? Like kaffe for instance or the jvm from ibm. Could we still pack it with the game without having problems with sun license ?
[/quote]
All jvms will have a license, and it’s unlikely that they are less stric than suns.

[quote]Or, even more radical, just include a full JRE (which has virtually no restrictions), get all the advantages of java, and not have to worry about the problem that sooner or later you’ll find there’s a bug in the version of java you distributed and now you have a massive great expensive pain trying to upgrade all your users.
[/quote]
Wich also includes 10 MB of crap I don’t use. And just because people download gfx drivers and directx does not mean it’s ok that my game is 10MB larger than it needs to be.

Why should a stripped runtime have any more bugs than the full runtime?

#49

What about the open source ones?

I for one am particularly pleased at how small java games are (considerably smaller than most C++ counterparts), and to a certain extent get annoyed that some people “just don’t get it”: java games are smaller, fact, and unless you are in a pretty special position (for instance, perhaps, the MCO game from Agency9), or especially arrogant, and genuinely know that your game will be the FIRST java game that significantly many of your players have ever played, or you have some particularly strong need to force the latest-and-greatest JRE version upon users (rare, but it doesn happen), then the size of the JRE is entirely irrelevant to everything.

Even when it is the first game they’ve played, or requires the latest features (e.g. 1.5.x), it’s far from guaranteed that the negative impact on your success is going to be greater than the positive impact from the fact that most people had a smaller download.

Shrug. It’s part of what java is (for the time being anyway), and whilst it’s ground that has been covered many times before on this forum, it’s something that undeniably becomes less of an issue every month (due to the increasing penetration of the JVM’s).

Whilst not claiming “it’s not an issue” (because I wish there were more choice here) - and eagerly awaiting the elusive carrot Chris dangled recently that suggests an alternative distribution path is about to be created, giving developers more choice - I’m getting a little tired of those who bring this up as a negative issue more on principle than because it’s actually caused them problems in the field. When someone does that, they are basically saying that they don’t want java-the-platform: you don’t pick a technology just by looking at it’s benefits, you pick it based upon all it’s features both good and bad. A large common standard runtime happens to be a fundamental feature of java-the-platform and the source of some of java’s great benefits.

NB: not that I’m accusing anyone in particular of bringing it up “on principle”, I’m just trying to make a general point.

I didn’t say it would; but a normal runtime has an established upgrade procedure that is extensively tested by hundreds of thousands of people. Upgrading a proprietary runtime requires you to do that work yourself, and you can bet Sun isn’t going to give you any help (unless you pay them, of course).

#50

[quote]What about the open source ones?
[/quote]
If they can match suns in quality and performance, then it would be a great option.

[quote]I for one am particularly pleased at how small java games are (considerably smaller than most C++ counterparts), and to a certain extent get annoyed that some people “just don’t get it”: java games are smaller, fact, and unless you are in a pretty special position (for instance, perhaps, the MCO game from Agency9), or especially arrogant, and genuinely know that your game will be the FIRST java game that significantly many of your players have ever played, or you have some particularly strong need to force the latest-and-greatest JRE version upon users (rare, but it doesn happen), then the size of the JRE is entirely irrelevant to everything.
[/quote]
Why are java games smaller? I don’t see the logic in this statement. Can you give an explanation.

What if the user don’t got a jre, or a to old jre? What if the user don’t even know if he got java installed? Force him to install java or have two versions of the game. In any case it makes it more difficult and confusing for the user.

[quote]Even when it is the first game they’ve played, or requires the latest features (e.g. 1.5.x), it’s far from guaranteed that the negative impact on your success is going to be greater than the positive impact from the fact that most people had a smaller download.
[/quote]
I think it would. But neither of us have any proof.

[quote]I’m getting a little tired of those who bring this up as a negative issue more on principle than because it’s actually caused them problems in the field. When someone does that, they are basically saying that they don’t want java-the-platform: you don’t pick a technology just by looking at it’s benefits, you pick it based upon all it’s features both good and bad. A large common standard runtime happens to be a fundamental feature of java-the-platform and the source of some of java’s great benefits.
[/quote]
A lot of people think it’s a problem. Probably THE greatest problem with making java games at the moment. I’m getting tired of those of put down anyone who bring this problem up.

But your right, I don’t wan’t java-the-platform. I wan’t to ship the vm with my game, with as little bagage as possible.

[quote]Quote:

Why should a stripped runtime have any more bugs than the full runtime?

I didn’t say it would; but a normal runtime has an established upgrade procedure that is extensively tested by hundreds of thousands of people. Upgrading a proprietary runtime requires you to do that work yourself, and you can bet Sun isn’t going to give you any help (unless you pay them, of course).
[/quote]
I don’t want to upgrade the runtime. The game would be tested with the one runtime. Once the game is shipped there would be no changes.

#51

There are actually several different scenarios as there are different types of games and different desired distribution approaches.

Java games will typically be smaller as long as you are not including the size of the JRE. A game that is heavily graphics oriented will be mostly graphics not code (this probably covers 90% of all games). In fact the size of the graphics will dominate the size of the code. Thus code size savings of Java become irrelevant. (Example Pernica - 500K code, 4+ Megs Graphics)

If distribution is via CD then there is very little issue, the full JRE can be included on the CD and all we are doing is wasting disk space on the customer’s hard drive. (I think I’m in the minority though in the fact that I do not like to waste space on the customer’s hard drive when it’s not necessary).

If however we wish to distribute electronically then we have an issue with how to deliver the JRE. For some Webstart might be a great solution. As a customer I’d never buy a game that I didn’t actually get and could reliably load on a new PC (see several posts up), thus WebStart is not an option I’ll consider.

So, ruling out webstart we are left with basically praying the customer has a properly installed JRE that is compatible with our game.

If we use something like Install4j to bundle the JVM into our game then we have potential legal issues (can our website meet the criteria to prevent downloading in a banned country?) and the download size becomes significantly large.

Yes, distribution of a java game is still my biggest concern with Java game development. Is the solution to only distribute via CD? (that certainly raises the cost of production!)

#52

[quote]If distribution is via CD then there is very little issue, the full JRE can be included on the CD and all we are doing is wasting disk space on the customer’s hard drive. (I think I’m in the minority though in the fact that I do not like to waste space on the customer’s hard drive when it’s not necessary).
[/quote]
Say the customer typically has like 30Gb of HD space and the JRE is 15Mb. You’ll be wasting 0.05% of their harddisk space. Worrying about this seems like a total waste of energy to me as your customers totally won’t care about such a little added installation size.

#53

[quote]Java games will typically be smaller as long as you are not including the size of the JRE. A game that is heavily graphics oriented will be mostly graphics not code (this probably covers 90% of all games). In fact the size of the graphics will dominate the size of the code. Thus code size savings of Java become irrelevant. (Example Pernica - 500K code, 4+ Megs Graphics)
[/quote]
example: sonic DX
60 MB exe
Java games are using png and jpg by default, other games might use RAW.

So that comparisson wasn’t exactly on the target.

#54

[quote]As a customer I’d never buy a game that I didn’t actually get and could reliably load on a new PC (see several posts up), thus WebStart is not an option I’ll consider.
[/quote]
This is a very good point. Perhaps Web start needs a way of saving off an application that is in the WebStart cache so that it can easily be reloaded into the cache. “Archive Application” anyone?

#55

It has actually come up quite often as a requested feature. It’s also been discussed on these forums at least once, and what to do about purchasing (basically: use webstart as the initial delivery mechanism, and you can use any mechansim you want for delivering the full-price version, webstart or not).

It would be nice if people could export, and there’s no good reason not to have the option (as we keep shouting at Sun…) but it’s no big deal…

FFS!!! If you can’t work out how to deliver a game over a transient link like that to your customers and allow them to re-download it if they lose the original copy then you probably shouldn’t be selling software in the first place! Seriously, this is basic online software delivery, and it’s the same issue irrespective of webstart: Most of us reformat our computers frequently; I expect to be able to re-download anything I purchased online, which is fair enough. Go look at shareware games, anything since oh 1995 will do. You will find plenty of different solutions to this “problem”…

PS: limiting to only post-1995 is being generous: I was buying online software that happily got around that problem years before that…

#56

[quote]FFS!!! If you can’t work out how to deliver a game over a transient link like that to your customers and allow them to re-download it if they lose the original copy then you probably shouldn’t be selling software in the first place! Seriously, this is basic online software delivery, and it’s the same issue irrespective of webstart: Most of us reformat our computers frequently; I expect to be able to re-download anything I purchased online, which is fair enough. Go look at shareware games, anything since oh 1995 will do. You will find plenty of different solutions to this “problem”…
[/quote]
I think most shareware games since 1995 has been distributed as a single file, a executable or a zip. This is great since even if the original company got bankcrupt and you can’t download it fromt it’s site, you can still have it as a backup, on a game mag cd or get it from a third party site like download.com. With webstart you can only get it from the original host, wich can disapear at any moment. Or were you thinking of some other solution?

#57

The problem is that you might not be able to download the code again if the company goes under etc.

E.g. I bought Roboforge, but after upgrading PCs I can’t play it because when I downloaded the new version I find that it uses a new method to register and so I’m screwed. I lost the original download.

#58

[quote]The problem is that you might not be able to download the code again if the company goes under etc.
[/quote]
Fair enough, but when the company goes under you usually get other problems too, so that I wonder how much of an issue this is in the long run. e.g. I have some games with fatal bugs that I know have been fixed but the company went bust before I could download the patches (and this wasn’t a fly-by-night … this was 3DO!). My only option was warez sites - download full copies of the games I’d already bought - but sadly there aren’t enough warez sites these days, and those that do exist have to be leaner and meaner than they used to be. Sigh. Too many self-righteous pricks with too many CD-based copy protection schemes making life hell for those of us who would like to play the games we’ve paid for, whilst knowing full well that the vast majority of piracy is done on mass printing presses in Asia. I wouldn’t be able to play mainstream computer games any more if it weren’t for all the kind people producing NO-CD cracks (how many CD’s/DVD’s can you fit in a small laptop bag without cracking them?)