Java-Gaming.org    
Featured games (79)
games approved by the League of Dukes
Games in Showcase (477)
Games in Android Showcase (107)
games submitted by our members
Games in WIP (536)
games currently in development
News: Read the Java Gaming Resources, or peek at the official Java tutorials
 
    Home     Help   Search   Login   Register   
Pages: [1] 2
  ignore  |  Print  
  Java Application Installation is a NIGHTMARE  (Read 6609 times)
0 Members and 1 Guest are viewing this topic.
Offline Andrew Davison

Junior Member


Medals: 2



« Posted 2004-08-20 03:01:42 »

Dear All,

I've been having a very interesting discussion with a
Java developer about the drawbacks of using Java
for application (e.g. game) development.

He came up with several problems related to installation.

Here we're talking about installing a Java
application
, to a platform with a naive user,
who doesn't want to become a Java hacker, and
doesn't even want to know that the application
is coded in Java. He wants to simply click and run it.

Ok, here are some drawbacks to using Java in
this situation:

  • a) Java (JRE) has to be on the machine before the
    application will run.

  • b) Code Bloat: Even small (<500K) programs require
    a ~15 Meg JRE. Downloading this can be very slow.

  • c) Frequently changing JVMs make it hard to write
    code that will work for every possible version of Java.

  • d) Non standard components are often required (e.g.
    Java 3D), causing even more installation problems.

  • e) It's not possible to compile the application for a
    specific platform.

  • f) The .jar extension is commonly hijacked by other
    software (e.g. by compression programs) at execution
    time. Meaning that the user can't just double click on
    the JAR to get it to start.

  • g) The JRE is slower to start up compared to a native
    compiled application.


Comments appreciated.

Installation is tough, which is why I've included
two appendicies about in my online book, one on
using install4j, the other on JWS. You can access
them at http://fivedots.coe.psu.ac.th/~ad/jg/.

- Andrew

Dr. Andrew Davison
Dept. of Computer Engineering
Prince of Songkla University, Hat Yai
Songkhla 90112, Thailand
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #1 - Posted 2004-08-20 03:28:11 »

Hmmm... where to start, other than saying the guy doesn't have a clue?

a) Is this any different to applications needing to install their own libraries, such as, say, Renderware. This is an application, it comes on a CD or an all-inclusive installer.  The end user never sees the JRE installation, particularly as you can do a private JRE install that only works for that app (see how the Oracle or MagicDraw products to this for example).

b) Try 5MB for the JRE., not 15. 15MB is about the total size of Xj3D's minimum installer, of which 8MB is InstallShield's own internal junk, 5MB is the JRE and the rest is Xj3D and all it's libraries.  5 years ago I would agree with the argument. These days I don't agree. Users seem to have no problems downloading 100MB album rips or 50MB patches for other games (last time I played StarWars Galaxies, the monthly patch size was just over a gigabyte!).  Also note the articles in the last few days that say the majority of americans now use broadband, so it's even less of an issue.  Anything beyond trivial applications are going to be far more than a few megs of downloads and as such Java apps are right on par for downloads.

c) Frequently changing versions of MS DLLs make is hard to write code that will work for every possible version of MS Win32 systems.  This is a non-argument.  LIke all good developers, you target a specific platform and set of libraries, then ship your applications including those in their own private installation path.

d) How many C/C++ applications require non-standard components? Anything non-trivial will. Again, a complete non-argument because it applies to all application development, not just Java.

e) Eh? Why not pick a specific JVM version and just develop to that. See above points.

f) No idea where he got that from. I've never seen any other application using a .jar extension on their file format.

g) Sometimes yes, sometimes no. Really depends on what your app is doing.  This is the only somewhat plausible reason that I could acknowledge.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline gregof

Junior Member




in code we trust


« Reply #2 - Posted 2004-08-20 06:59:32 »

Hi
While I totally agree with Mithrandir, I just wanted to add that there actually are a couple of applications that use the .jar extension (file compression programs comes to mind) and I found this with our friend google: http://www.filext.com/detaillist.php?extdetail=JAR
I use winrar on occasion and if you are not carefull when installing it, it can register the .jar filetype.


// Gregof
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline oNyx

JGO Coder


Medals: 1


pixels! :x


« Reply #3 - Posted 2004-08-20 07:26:10 »

a) Same goes for graphic card drivers, sound drivers and directx. The graphic card drivers alone are bigger than the JRE these days.      

b) You can't call that "bloat". Eg no one "adds" directx to their filesize. It's a one time download and if the user installs/uses several java applications it's infact smaller than native applications.

c) Uhm... no. Not really. Well, it's pretty save if you target the latest official version. Any changes which actually affect your program in any way are really rare. Got that once, because I relied on default insets of JButton, but that was fixable with some lines of code.

d) I just add that stuff. Usually I just put it into the same jar. Well, that won't work for Java3D, I guess.

e) I don't see a problem here. However, technically you can.

f) Yes, that's pretty annoying. However, you can add a native launcher if you want to. (Not necessary with webstart)

g) Doesn't matter in most cases. It's usually a noticable drag for small silly command line tools - nothing you've to worry about if you write a somewhat bigger application (eg a game)

---

For the native launcher... jbanes (iirc) had posted some C++ code which searches for java in the registry and starts it (with some parameters, specified at compile time).

弾幕 ☆ @mahonnaiseblog
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #4 - Posted 2004-08-20 09:47:29 »

In addition to the previous responses...

Quote
Dear All,
He came up with several problems related to installation.


Mostly these are not problems at all. I'm surprised you listed them as such - surely you are well aware that most of this is specious? I'm guessing you started this thread to spread awareness of the FUD that was common amongst some people, rather than because you had any doubts of your own?

Quote


  • a) Java (JRE) has to be on the machine before the
    application will run.


As we all know by now, more than 50% of all new PC's come with this already, including an auto-updater.

We also know that MS has been encouraging people to install Sun's JRE (at least for the duration of the trial when they were banned from distributing their own one to new users)

Quote

  • c) Frequently changing JVMs make it hard to write
    code that will work for every possible version of Java.


Rubbish. You *never* want or try to write code that "will work for every possible version". There are only two versions that matter: 1.1.7 MS and "latest" Sun. And the former of those is fast disappearing...

90%+ of the libraries that we use today have been in java since 1997, which is a heck of a long time. The 99% of the remaining 10% arrived with 1.4 - which everyone should be using anyway.

Your statement is akin to complaining that windows 95 programs don't run on windows 3.1 (and yes, there *are* still people running windows 3.1!); only, with java there is *no* reason not to upgrade, and it's free, and it's 99% backwards compatible.

Quote

  • d) Non standard components are often required (e.g.
    Java 3D), causing even more installation problems.


Ahem. That's why http://grexengine.com/sections/externalgames insists on webstart - this problem *does not exist* if you distribute your games properly.

There are a small number of exceptions (c.f. other threads for the list of problems with webstart at the moment, some of which can be showstoppers), but on the whole this problem is due to incompetence on the part of the developer, nothing to do with java. If Sun fixes all the webstart bugs, then almost all the excuses should disappear...

Quote

  • e) It's not possible to compile the application for a
    specific platform.


Why on earth would you want to? The only outcome is that your application becomes less dynamic, slower, and won't benefit from future JVM upgrades.

EDIT: I meant "why ... would a normal developer ... want to?". Of course there are advantages, the most obvious of which are reduced filesize and reduced startup time. When I said "only" I can only beg forgiveness for typing pre-coffee (haven't had time for a break yet this morning)...I was talking BS.

Even if you do want to, the claim is wrong, since you've been able to natively compile for years (IIRC I've seen native compilers since all the way back in 1998, although they only had limited coverage of the standard libraries).

Quote

  • f) The .jar extension is commonly hijacked by other
    software (e.g. by compression programs) at execution
    time. Meaning that the user can't just double click on
    the JAR to get it to start.


Nothing to do with java - that's a bug in the other software. Almost all software these days only associates unassociated filetypes, except it's "core" types that it absolutely must have (e.g. winzip grabs ZIP, plus anything that is untaken).

malloc will be first against the wall when the revolution comes...
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #5 - Posted 2004-08-20 09:51:14 »

a) and b) are basically the same issue. True, it's a one-time download, but for many people on slow connections with no pre-installed JVM, this *is* still an issue.

c) I only encountered some problems related to beta versions. Never had compatibility problems with new, final releases.

d) I believe j3d (being open sourced and all) can be webstarted or otherwise included in the game and linked to nowadays. I can't think of any other extension that needs a separate install procedure and can't be simply included in the game.

e) As pointed out, you can if you can stand all the hassle required. But why would you want that? Isn't it easier to leave those problems to the JVM engineers?

f) Just think that there's no such thing as an "executable jar". It's a bad idea anyway and not needed.

g) With the server VM, this can be true. However, your internet distributed game won't run on the server VM, but on the slower, but quickly starting client VM. However, the client's lower performance *can* be a problem in some situations where most raw computing power is needed. In most cases though, the client is just fine.
So in my opinion, the problem is not start-up time itself, but the fact that there is a trade-off between performance and start up time. And added to that, the fact that the 'slower start-up but best performance' option is not really an option because the server VM is not included in the JRE (which totally makes no sense IMO). You won't convince any casual game player to go download the JDK and fiddle with the game to use the server vm.

Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #6 - Posted 2004-08-20 10:47:30 »

Quote

a) Java (JRE) has to be on the machine before the  
application will run.

Not necessarily. The delivery mechanism needs to be adjusted to provide the correct download. For example, a web page can detect the availability of Java and provide a JNLP link; failing that it can display a page containing links to .exe installers which bundle the VM and then install the application via Webstart.

Quote
b) Code Bloat: Even small (<500K) programs require  
a ~15 Meg JRE. Downloading this can be very slow.

Only the once. There are very many software dependencies in computing these days and by and large, no computers run "correctly" out of the box. Even setting up a brand new computer usually involves downloading about 50mb of drivers and patches on XP. Having said that, 15mb is an outrageous size for the VM. It needs to be sub-5mb and packaged modularly.

Quote
c) Frequently changing JVMs make it hard to write  
code that will work for every possible version of Java.  

Most of the incompatibilities come from AWT. So use the LWJGL Smiley

Quote
d) Non standard components are often required (e.g.  
Java 3D), causing even more installation problems.

Not under Java Web Start.

Quote
e) It's not possible to compile the application for a  
specific platform.

Who cares?

Quote

f) The .jar extension is commonly hijacked by other  
software (e.g. by compression programs) at execution  
time. Meaning that the user can't just double click on
the JAR to get it to start.

We don't use JARs any more to run things. It's all JNLP now. Anyone using JAR deployments should be hung by the toenails until thoroughly repentant.

Quote

g) The JRE is slower to start up compared to a native  
compiled application.

Very true, and a major bugbear. I see several solutions which are as likely to come out of Sun as the Devil from my arse:

1. Two-stage VM - ditch the client VM and instead use a hybrid VM that compiles code in two passes, once with the client optimisation, and later on using the server optimisations. I regard this as essential for Java gaming to flourish as the client VM simply isn't fast enough on Win32.

2. Caching machine-format classes: if a JNLP file wants a JAR, it could convert the whole JAR into the internal format used by the VM and from then on simply map it into memory if it hasn't changed.

2a. Caching hotspot profiling information against JNLP files. Why learn everything again from scratch when you can start with the assumption that the next time the application is run it will probably behave the same as last time? Even the compiled machine code could be cached in this way. The VM engineers mumble stuff about the possibility that the code will behave differently and that the optimisations will no longer be valid but rarely take into account the probability that this is very unlikely...

Cas Smiley

Offline Mithel

Senior Newbie




Global Contribution, for the greater good of all.


« Reply #7 - Posted 2004-08-20 13:10:11 »

On a Java forum we can expect he majority to respond that such concerns are false, yet in even the few responses there is disagreement and indications these points are valid.

I suspect many of the responses might also be from people that do not have deployed Java applications.  I've deployed over a half dozen Java utilities/applications and one major online game.

a) The JRE must be installed.

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?)

b)  Code bloat - JRE is 15 Meg.

True, the JRE 1.4.2_05 is a 15 Meg download.  We might argue that it only needs to be downloaded once, but that's not true if the application is updated and thus requires a new updated JRE.

c) Frequently changing JVMs.

This is a problem.  I had a nightmare experience with a 3COM switch with management software written in Java that forced[/] an install of an older JVM trashing a perfectly well set up Java environment.  I've had numerous customers that have had issues running Java software where the solution was to uninstall all JVMs and cleanly reinstall.

The simple fact is that applications (unless packaged with their own JVM) are at the whim of JVM versions and install issues.

d) Non-standard parts of Java.

Up until just a couple months ago Java 3D was not open source and was a cause of many headaches for many developers because we could not legally post a copy of it (due to export restrictions to banned countries) thus requiring pointing the customer to Sun's website and requiring a separate install (good luck directing the naive customer to get this installed into your own copy of the JVM!).

e) Native compiling

This is very desirable.  It allows small applications to be distributed as a single file and be reliably run without concerns about other software (JVMs, DLLs) changing.

And native applications do start up much faster than Java applications.

Heck, it's not like we don't have separate distributions of Java applications for Linux and Windows already! (OpenOffice is a perfect example)

f) jar extension hijacked

WinRAR and UltimateZip both hijack the .jar extension.  This has caused me personally several flurries of e-mail exchanges with customers to solve the problem.

g) JRE start up slow

This is a subjective opinion.  Personally start up speed is one of my biggest concerns with any application and it's a flaw in Java that annoys me.  Typically for a major application it's not a real issue though.  It's just an annoyance.

Some responses have indicated WebStart is a better deployment method than using a Jar file.  I absolutely detest WebStart and refuse to run ANY application that is deployed via WebStart.

Deploying via Jars (if the other issues were addressed) is an elegant and ideal solution.  A single Jar file would be as good as a single EXE if the other issues didn't exist. (Jar files can solve a lot of the classpath issues that plague Java)

I've had other developers express the opinion that a native compiler (for each platform) would be the number one most desired feature to add to the JDK.  I agree, if Java had a native compiler (for both Linux and Windows) I wouldn't be throwing away eight years of Java support and development and switching to another language.

When I started learning Java my reason for choosing Java was that I believed in it's long term lifespan (after learning a couple dozen other languages I was tired of constantly learning new programming languages).  Unfortunately Java hasn't lived up to my expectations so after eight years of promoting and developing in Java I'm walking away.
Offline Mark Thornton

Senior Member





« Reply #8 - Posted 2004-08-20 14:16:06 »

Quote
b)  Code bloat - JRE is 15 Meg.

True, the JRE 1.4.2_05 is a 15 Meg download.

That is the multilanguage version. I seem to remember that there is a smaller version for Americans! The JRE5 beta 2 download is about 1MB smaller despite the increase in capability.
Quote

 We might argue that it only needs to be downloaded once, but that's not true if the application is updated and thus requires a new updated JRE.

Java Update should mean that you don't have to download the whole thing again. OK so this doesn't yet work as well as it could.

Quote

This is a problem.  I had a nightmare experience with a 3COM switch with management software written in Java that forced an install of an older JVM trashing a perfectly well set up Java environment.  I've had

I've had problems with software overwriting MSVC runtime dlls with older versions, resulting in absolute mayhem. To avoid this completely you would have to supply everything down to the OS and perhaps even the processor!

Quote

Heck, it's not like we don't have separate distributions of Java applications for Linux and Windows already! (OpenOffice is a perfect example)

?? OpenOffice is written in C++.

Quote

Some responses have indicated WebStart is a better deployment method than using a Jar file.  I absolutely detest WebStart and refuse to run ANY application that is deployed via WebStart.

What problems do you find with WebStart. That latest versions seem very good. In particular the coming j2se5 version seems to have resolved most of the shortcomings I know of.
Offline colesbury

Senior Newbie





« Reply #9 - Posted 2004-08-20 14:38:04 »

Quote
As we all know by now, more than 50% of all new PC's come with this already, including an auto-updater.

I noticed that the autoupdater doesn't seem to work. Is (or was) the autoupdater broken?
Anyone know much about JSR 200 (http://www.jcp.org/en/jsr/detail?id=200)? Looks like it will allow for smaller downloads of the JRE.

Quote
b) Try 5MB for the JRE., not 15. 15MB is about the total size of Xj3D's minimum installer, of which 8MB is InstallShield's own internal junk, 5MB is the JRE and the rest is Xj3D and all it's libraries.  

Is there a way I can distribute a 5MB JRE?  

Quote
5 years ago I would agree with the argument. These days I don't agree. Users seem to have no problems downloading 100MB album rips or 50MB patches

There is still a lot of people with dialup (~49%).  Also, I remember Cas saying that downloads decrease drastically when the file is >10MB

-Sam
Games published by our own members! Check 'em out!
Legends of Yore - The Casual Retro Roguelike
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #10 - Posted 2004-08-20 14:44:51 »

Some of your statements are dodgy and contentious; I'll leave those aside to concentrate on the one big mistake you make:

Quote

Some responses have indicated WebStart is a better deployment method than using a Jar file.  I absolutely detest WebStart and refuse to run ANY application that is deployed via WebStart.

Deploying via Jars (if the other issues were addressed) is an elegant and ideal solution.  A single Jar file would be as good as a single EXE if the other issues didn't exist. (Jar files can solve a lot of the classpath issues that plague Java)


NO! You may well have big "issues" with webstart, but as long as you believe that JAR files are a decent replacement you do not yet fully understand the issues.

NB: please contribute to the thread cataloguing webstart's problems - that way you can help get it fixed without lifting a finger. http://www.java-gaming.org/cgi-bin/JGNetForums/YaBB.cgi?board=announcements;action=display;num=1091989308

Webstart mainly attempts to solve the following issues that JAR's do not, cannot, and will not:

- JVM dependency management
- minimizing wasted download time by re-using shared components
- performing *automatic* version management
- *automatic* extensions installation
- sandboxing of extensions so that they CANNOT interfere with the primary JRE

You can, of course, write an application to do all these that uses JAR's as the distribution format, only...quel surprise!...you end up with webstart (the only differences being in the GUI, the style, and the bugs).

Quote

I've had other developers express the opinion that a native compiler (for each platform) would be the number one most desired feature to add to the JDK.


This is something you hear often from inexperienced java programmers, especially those who know a lot more C++ than they do Java, and who *think* they know java a lot better than they do.

If you are so desperate for a sun-distributed native compiler then you almost certainly do not know java well enough yet. I'm not claiming there aren't good reasons for wanting native compilation, but in general they commit you to disadvantages that vastly outweigh the advantages. But as already noted you do already have native compilation if you really really need it. It's just that the vast majority of developers know that they don't.

I suggest you c.f. the RFE list for java, and see how far down "add native compilers to the JDK" comes. That should give you pause for thought - you ought to wonder why the vast majority of java developers want something else instead.

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #11 - Posted 2004-08-20 14:49:26 »

Quote

There is still a lot of people with dialup (~49%).  Also, I remember Cas saying that downloads decrease drastically when the file is >10MB


I see where you're coming from, but really it's not so relevant as you think. The main point is that if you want to play games today, you have to download 60Mb + for your graphics card driver every few months, which is more data more often than you have to download the JRE. Therefore, what users are willing to *accept* is much higher than it used to be.

I speak as someone who until not so long ago still had SLOW dialup at home, and even now regularly uses dialup (laptop; not enough internet cafes!). You find a download manager, you stop whinging, you put on your download, go make lunch, and you cross your fingers and dream of the day when your neighbourhood gets broadband.

Incidentally, I noticed this week that even somewhere as out of the way as the tiny island of Malta in the middle of the Med has fast cheap ADSL access now!

malloc will be first against the wall when the revolution comes...
Offline princec

JGO Kernel


Medals: 343
Projects: 3
Exp: 16 years


Eh? Who? What? ... Me?


« Reply #12 - Posted 2004-08-20 14:51:07 »

Downloads are apparently stepped at 5mb, 10mb, 30mb, 100mb and >100mb, where at each step we see a drastic reduction in downloads.

However next year there will for the first time be more broadband punters than dialup for most of the G8 countries so I think we're going to see a shift up one step.

Btw - native compilation won't help us any. Especially as quite a few of us might use dynamic class loading as it's a core language feature.

You can deploy a naughty cut-down embedded VM in your application, nod nod, wink wink, say no more. I've got it down to under 3MB in Alien Flux for Windows.

And there are native compilers for Windows and Linux (see Excelsior JET - totally awesome bit of technology) if you find you need them. You get C++ start up time and -server execution speed, and some extra headaches which I needn't go into.

Cas Smiley

Offline Mithel

Senior Newbie




Global Contribution, for the greater good of all.


« Reply #13 - Posted 2004-08-20 14:54:42 »

Yes, the 15 Meg JRE 1.4.2_05 is multi-language.  Can anyone find a smaller one?  Are we supposed to tell our customers to hunt for a smaller one when we can't find it ourselves?

Java Update... ah yes the new option they don't even ask you if you want enabled now.  So how long till all software has auto update features that clog our systems constantly checking for new versions?  (Sigh... no wonder we keep needing more and more RAM)

Oh, there is no shortage of software created with DLL version issues but not all software needs these services (and thus can be a stable EXE that never needs to change and doesn't break unless you migrate to a *new* OS)  Heck, I've got Win31 applications that still run without being touched on WinXP.  This doesn't prove anything.

If OpenOffice is C++ then why does it require a JVM?  Hmm... ok, looks like it is a hybrid multi language development.

My primary issue with WebStart is that it usually includes prompting asking a naive user to relax security settings and it leaves files on a user's hard disk (in locations generally not known).  How do you uninstall a WebStart application?

Webstart is far too much like Microsoft's WinXP "trust us we won't mess up your machine" auto update concept. (something I'm not too pleased with since in the last month I've suffered a completely erased hard drive due to a WinXP update failure)

Will Webstart work for deploying to non networked PCs?  What if you have 20 or 200 or 2000 machines you want to install on - with WebStart that means a lot of bandwidth to download rather than a distributable CD.

Just to refresh my memory I fired up WebStart on a test machine and tried to run "Military Game App".  The first thing it does (after a small download) is ask the user if they want it integrated with their desktop.  Does a naive user even know what this means???  After running it, it's now "downloaded" on my PC... no option to uninstall it (and no information as to where it's located).

Now I know a lot of people say hard disk space isn't an issue, RAM isn't an issue... "it's cheap, modern machines have plenty, etc".  Well, I for one, do care about hard drive space, I do care about memory bloat.  And I consider it rude to "infect" someone's machine with your application without giving them a clear and easy way to uninstall and delete it.

Simple fact is that WebStart is not a "cure all".  There are situations with WebStart that aren't acceptable.
Offline Mithel

Senior Newbie




Global Contribution, for the greater good of all.


« Reply #14 - Posted 2004-08-20 15:00:12 »

Yes, there are native compilers (Jet) but have you ever looked at the limitations they impose?  Sorry, but they aren't a real option with Java.
Offline Mithel

Senior Newbie




Global Contribution, for the greater good of all.


« Reply #15 - Posted 2004-08-20 15:03:12 »

If you don't believe Application Installation is a nightmare then you haven't been an active member of the Java 3D forum for the past three years reading one person after another asking for some decent way to deploy a Java 3D application.  (and all the confusion over Sun's legal position regarding online distribution)
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #16 - Posted 2004-08-20 15:05:48 »

DON'T rant here, read the thread I quoted and respond there - although please don't repeat what's already been said because "me too" posts aren't much help; just outline the problems you have that are different to those already listed.

Quote

My primary issue with WebStart is that it usually includes prompting asking a naive user to relax security settings and it


Improved for 1.5, and for many people a benefit rather than a problem. If you were up to date on windows, you'd know that MS is moving MORE in this direction at the moment (c.f. changes introduced by XP SP2)...this is about to become a fact of life rather than something that only a few groups like Sun do...

Quote

How do you uninstall a WebStart application?


Add/Remove programs, surprisingly enough (next version - i.e. it's been fixed, but obviously we have to upgrade to get the fix!)

Quote

Will Webstart work for deploying to non networked PCs?


Of course, and if you try to deploy to 2000 PC's you will have what is known as an automated distribution server (nothing to do with java) and you will already have processes that make it effortless. I've been there, done that, it's easy. We are, however, talking about games, and I've yet to see the corporate that was interested in putting a game on everyone's desktop!

Quote

small download) is ask the user if they want it integrated with their desktop.  Does a naive user even know what this means???  After


It asked me if I wanted a shortcut on the desktop, and yes - every damn windows user knows what that means, because windows is FOREVER talking to you about shortcuts.

You might as well complain "this window pops up with two buttons.  Does a naive user even know how to click on a button???"

You need to get some perspective Grin...

malloc will be first against the wall when the revolution comes...
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #17 - Posted 2004-08-20 15:08:04 »

Quote
If you don't believe Application Installation is a nightmare then you haven't been an active member of the Java 3D forum for the past three years reading one person after another asking for some decent way to deploy a Java 3D application.  (and all the confusion over Sun's legal position regarding online distribution)


That makes no sense at all. You agree that this is no longer the case, yet you hold it up as a reason why application installation *IS* a nightmare? Huh

You mean, surely, "WAS", and hence it doesn't really matter any more...

Of course, Java3D has been an unsupported tech for some time, so to a certain extent those devs have themselves to blame for ongoing problems (and can only blame sun for initially killing the tech, not for the problems that ensued thereafter)

malloc will be first against the wall when the revolution comes...
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #18 - Posted 2004-08-20 15:13:43 »

Quote
After running it, it's now "downloaded" on my PC... no option to uninstall it .


Application -> Remove application

As simple as that!

Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #19 - Posted 2004-08-20 15:29:13 »

Quote
My primary issue with WebStart is that it usually includes prompting asking a naive user to relax security settings and it leaves files on a user's hard disk (in locations generally not known).


It doesn't ask to relax security settings at all, it's more like the opposite! It warns about potential security risks involved in running code regarded as "unsafe". You don't get that warning with .exe or executable jars because the "security settings" with those are as relaxed as they can be (absent with .exe).

Offline Mark Thornton

Senior Member





« Reply #20 - Posted 2004-08-20 15:31:14 »

Quote
Yes, the 15 Meg JRE 1.4.2_05 is multi-language.  Can anyone find a smaller one?  Are we supposed to tell our customers to hunt for a smaller one when we can't find it ourselves?

Go to www.java.com and use the web installation. I believe the installation process then gives at least Americans the option of a smaller download (by omitting support for all those locales they have never heard of and couldn't find on a map :-) ).

Quote

software has auto update features that clog our systems constantly checking for new versions?  (Sigh... no wonder we keep needing more and more RAM)
This is just a fact of life. Have you noticed all those downloads of Windows XP SP2 yet?

Quote

If OpenOffice is C++ then why does it require a JVM?  Hmm... ok, looks like it is a hybrid multi language development.
The core is C++. Extensions can be written in Java.

Quote

My primary issue with WebStart is that it usually includes prompting asking a naive user to relax security settings and it leaves files on a user's hard disk (in locations generally not known).
Windows is asking if you really want to run anything downloaded from the web now. It even (irritatingly) asks every time I run an app located on a share on a local server. Most users don't care where the application resides, just where their data is.
Offline Mithel

Senior Newbie




Global Contribution, for the greater good of all.


« Reply #21 - Posted 2004-08-20 15:48:00 »

erikd, thanks, never even noticed "Application; Remove Application" (as you can tell I've barely touched WebStart).

blahblahblahh - just stating that someone else doesn't know what they are talking about (calling them inexperienced) doesn't make for a strong argument for your position.

As best I can tell your postion is:
 1) Application deployment won't be an issue when the next version of Java (1.5) is released.
 2) Go with the flow and do things you don't like just because the rest of the world is doing it (Microsoft and auto update).
 3) Java 3D applications aren't a problem anymore because Java 3D has been released to open source. (What about other non-standard Java extensions?)

Hmmm... if WebStart is such a great solution why does it require books published just on Webstart? (  http://java.sun.com/developer/Books/javaprogramming/jnlp/ )  How do I deploy a WebStart application to a user that isn't connected to the Internet?  WebStart requires all application resources to be packaged in Jars... well that would require a major rewrite for one of my games. Ouch!

Well... this thread looks like it's going no where.  It's become an issue of whether or not WebStart is the solution to all of Java's deployment issues.
Offline Mark Thornton

Senior Member





« Reply #22 - Posted 2004-08-20 16:12:26 »

Quote
WebStart requires all application resources to be packaged in Jars...

Is there any good reason for a resource to be anywhere else? If they really can't stay in a jar, they could still be delivered that way and copied to an ordinary file after installation. We have some resources not in jars, but that was a mistake by the developer concerned.
Offline Mithrandir

Senior Member




Cut from being on the bleeding edge too long


« Reply #23 - Posted 2004-08-20 16:16:22 »

Quote
If you don't believe Application Installation is a nightmare then you haven't been an active member of the Java 3D forum for the past three years


I've been developing professional Java applications for 8 years now (the smallest one had a budget of US $500K, so they're not trivial apps by any definition). My first application that used Java3D as a part was shipped in 1998. It has never been a problem in any of the ways defined in the original post or followups.  If people are finding it a problem, they don't know what they are doing (inexperience, incompetence or otherwise), as it is certainly not a fault of the environment.

Quote
Hmmm... if WebStart is such a great solution why does it require books published just on Webstart?


Because publishers see an oppourtunity to make money. That's it, pure and simple.  New technology, flavour-of-the-month stuff, nobody else has a book on it, so let's get one out there to make some sales.  If you applied your logic to book sales in general, then Windows must be hard, or Machintosh or cooking, or any other reason to justify such classics as Foo For Dummies. FWIW, I've written or contributed to 10 books now, so I have a reasonable idea of their motivations for starting a book.

The site for 3D Graphics information http://www.j3d.org/
Aviatrix3D JOGL Scenegraph http://aviatrix3d.j3d.org/
Programming is essentially a markup language surrounding mathematical formulae and thus, should not be patentable.
Offline Mark Thornton

Senior Member





« Reply #24 - Posted 2004-08-20 16:22:42 »

For people who want their installers to appear traditional (i.e. not WebStart) there is the JDIC packager https://jdic.dev.java.net/documentation/index.html#packager which takes a webstart application and wraps it up as an MSI, RPM or PKG installation for Windows, Linux or Solaris respectively. Unfortunately it requires the new import mechanism in J2SE5.
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #25 - Posted 2004-08-20 17:06:31 »

Quote
Hmmm... if WebStart is such a great solution why does it require books published just on Webstart?


I don't see any relation between jws' competence and a book being available about it. If every technology which a book is written about sucks, then... well... is there any technology left?

Offline CaptainJester

JGO Knight


Medals: 12
Projects: 2
Exp: 14 years


Make it work; make it better.


« Reply #26 - Posted 2004-08-20 17:09:24 »

Quote


Application -> Remove application

As simple as that!

Does not work properly.  Tried this with JRE1.4.2 because I was having problems with a webstarted app.  When I told WebStart to remove it, it only removed it from its list.  It did no remove the app from the harddrive.  Then after I manually deleted it, I tried to run it again and WebStart complained about not being able to find files.  The next thing for me to try is to delete the WebStart cache(which I later discovered).  
However, it is not easy to remove a WebStart app properly.

ps.  I am an avid Java supporter, I just wish WebStart worked better.

Offline Mithel

Senior Newbie




Global Contribution, for the greater good of all.


« Reply #27 - Posted 2004-08-20 17:34:18 »

erikd - WebStart doesn't suck, but it doesn't appear to be a non-trivial solution.  I've looked at it (briefly) and it certainly appeared that it would take some effort to package up an application for Webstart (and a book on the subject seems to imply that it's non-trivial).

Certainly WebStart has some great concepts.  My exposure to it so far has been completely negative though.  I simply don't like it.  That doesn't mean that it sucks (just that I don't wish to use it).

Contrast WebStart to simply copying an EXE file.  Night and day difference.  With Delphi, or C, etc there is no "installation" just hand the EXE to your customer and that's it.  With WebStart we need to design the application for Webstart, we potentially have "signing" issues for producing the Jars, various versions of WebStart, potentially issues with which version of JRE we specify is needed to run our application (thus potentially triggering a large download for the user), the customer must have a network connection (preferably high speed) and customer confusion (most of them don't even know WebStart exists).
Offline blahblahblahh

JGO Coder


Medals: 1


http://t-machine.org


« Reply #28 - Posted 2004-08-20 17:57:48 »

Those reasons are all FUD, bar one (the offline install, which can be easy but requires enough work at present to be a PITA). You are basically saying "i've glanced briefly at something which I certainly don't fully understand yet and because I noticed that a book existed it confirmed my worst fears that this would be difficutl to use". That's not logical, that's FUD; if you wanted some REAL evidence one way or the other you could simply have looked at the poll results in the thread I quoted - would the overwhelming majority of respondents be webstarting their games if it were really so hard, do you think?

malloc will be first against the wall when the revolution comes...
Offline erikd

JGO Ninja


Medals: 16
Projects: 4
Exp: 14 years


Maximumisness


« Reply #29 - Posted 2004-08-20 18:00:14 »

It took me just 2 hrs at most to learn how to deploy using web start, and that's including the search for docs and reading them (if you read the coke & code tutorial, you're done in 10 minutes). That doesn't mean there's not a lot to know about.
I don't think web start is perfect. In fact I think there are things which are plain annoying. However, I still firmly believe in the concept and that it's perfectly usable for deploying games and also other apps.
I also developed a client-server app for work, with a little embedded http server only for jws. The client is installed using web start by pointing the browser to the machine name and clicking the 'start' button on the index page (which also has a link to a jre). When there's an update, only the jar has to be replaced on the server and the clients are automatically updated. I only received very enthousiastic responses from the customers about the ease of it all. Delivering .exe files is no option in that case.

Of course, indie games might be easily deployed via a simple .exe and yes, there's less hassle involved in there for the user if he doesn't already have a jre.
But what if the game is big (think >50Mb), popular, and in need of an update? I'd wish it were deployed via webstart and automatically patched.

Pages: [1] 2
  ignore  |  Print  
 
 
You cannot reply to this message, because it is very, very old.

 

Add your game by posting it in the WIP section,
or publish it in Showcase.

The first screenshot will be displayed as a thumbnail.

Riven (15 views)
2014-07-29 18:09:19

Riven (10 views)
2014-07-29 18:08:52

Dwinin (10 views)
2014-07-29 10:59:34

E.R. Fleming (28 views)
2014-07-29 03:07:13

E.R. Fleming (10 views)
2014-07-29 03:06:25

pw (40 views)
2014-07-24 01:59:36

Riven (39 views)
2014-07-23 21:16:32

Riven (27 views)
2014-07-23 21:07:15

Riven (29 views)
2014-07-23 20:56:16

ctomni231 (59 views)
2014-07-18 06:55:21
HotSpot Options
by dleskov
2014-07-08 03:59:08

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:58:24

Java and Game Development Tutorials
by SwordsMiner
2014-06-14 00:47:22

How do I start Java Game Development?
by ra4king
2014-05-17 11:13:37

HotSpot Options
by Roquen
2014-05-15 09:59:54

HotSpot Options
by Roquen
2014-05-06 15:03:10

Escape Analysis
by Roquen
2014-04-29 22:16:43

Experimental Toys
by Roquen
2014-04-28 13:24:22
java-gaming.org is not responsible for the content posted by its members, including references to external websites, and other references that may or may not have a relation with our primarily gaming and game production oriented community. inquiries and complaints can be sent via email to the info‑account of the company managing the website of java‑gaming.org
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2013, Simple Machines | Managed by Enhanced Four Valid XHTML 1.0! Valid CSS!