Nothing wrong with LWJGL, it all still works.It's just some behaviour of some things in 1.5 that has changed. Granted, some of it might be my own fault (I admit that directly including org.apache.xpath.XPathAPI in Cosmic Trip wasn't exactly smart), but still...

I got shitload of code at work which can run only on 1.3 and not 1.4, and 1.4 code which can't run on 1.5 .. (mostly client applet code) so if the customer upgrade the JVM .. kaboom.. plus it's not my code, it's third party propietary one, so I can't upgrade it :-/

Which is one of the reasons applets and webstart suck for game distribution. JVM upgrades break code too often.The only way to be sure your code will be working one year from now is to either use a native compiler or use an embedded VM.Things that makes you go hmmmm.... :-/

You can specify the exact version of the JVM or an entire range of JVM versions for JWS. There are other things that suck about JWS, but JVM versioning is not one of them.

So, say a casual user has gone through the lengths of downloading the huge 1.5.0 JVM and your code specifically asks for 1.4.1, he has to download a huge JVM again. He starts another game asking for 1.4.2, another huge download. If the casual user was just curious about the games in the 4k competition, well imagine his joy....And in applets, you can't specify a version.of course it's not as bad as I make it look now, but my point is that this exact versioning shouldn't be necessary. It would be nice if I had a game developed in 1.3, it would still work without thinking about future incompatibility problems. Now realisitically, shit happens, but JVM incompatibility problems have affected me a little too often.

1) The JVM is not huge. It's actually pretty small. People don't download the JDK, they download the JRE.2) People don't casually download JVMs. They download a JVM to run an app.3) If you want to let your users run your app on an "uncertified platform", that's your choice. You can always write another JNLP that says "run my program on any JVM version, but it's not certified.4) The whole idea that you can magically run your apps on a new platform and never expect any incompatibilities in the upgrade is basically ludicrous. This has nothing to do with Java - it's a general software reality.

1) for me and my internet connection, it is2) of course. I don't know how this relates to my point3) ok, that might be an option for web start4) of course; that's what I meant with my "shit happens" comment. My main point is that JVM incompatibilities happened a lot more to me lately than I think would be 'as expected'. So right now I'm in "pissed off trolling mode", that's all. But maybe I should just shut up and just fix all my code... again. Or just let my users screw themselves for a while, while I read a book and calm down

- webstart revolves around the idea of making the JVM a shared, dynamic, library, something that each app doesn't need to provide a private copy of. - if there are relatively few versions, and lots of applications, then most users will nearly always already have the required JVM version

It works *because* there are many more apps the user downloads than there are JVM versions they might realistically use. At any one time, there are typically only 3 valid JVM versions in existence (for windows and linux) - latest, latest-but-one (due to x.x.x_YY regression bugs - with 1.5 still so young, this is applied to the 1.4.2 at the moment instead), and previous-platform (i.e. 1.4.2 at the moment)

There's really nothing to complain about here: either there are enough games/apps that it works, or there aren't. Why was JGF created? Partly to put a large amount of such games/apps in one place, because doing so makes webstart "work for the user". If you find yourself saying something like: "my users keep being asked to download more JVMs all the time" this is really a reflection of the fact that they haven't upgraded when they should have (ignored the auto-update in windows!) or that your JNLP's are wrong, referencing out of date crappy JVM's, or that your code is wrong, relying on bugs in the standard libraries WHICH YOU NEED TO FIX RATHER THAN RELY ON THEM.

1. There are almost no incompatibilities with "real" java versions, the ones that people use in production (i.e. 1.4.2 etc). Just because a lot of developers are (mostly without thinking much about it, I suspect) switching to 1.5.0 doesn't change this; most people are not doing this precisely because they/we know that this has never been a good idea with any Sun software ever, and has always caused large amounts of pain.

Although, I suppose I ought to be grateful that you lot are beta-testing the JVM so that eventually it will make it to 1.5.1 or 1.5.2 or 1.5.3 and become "usable".

Um, except of course the mind-numbing: "We created chaos and confusion by releasing 1.3 so that the compiler produced stuff that crashe pre-1.3 JVMs. Because we're so stupid, let's do it all over again! We didn't quite get enough bad press about how crap java was last time (heck, there was a lot, but it blew over after a while; we need some more free publicity!), so let's really roll out the barrel this time".

/me thinks the shareholders of Sun Microsystems really need to start firing some of the morons they employ

2. Java 5 is most definitely NOT something "up to date" that users ought to be upgrading to or else the bugs they experience are "[their] fault". Despite the begging of high-level Sun executives, relatively few people with wisdom on their side have migrated to java 5 for production use; Sun hasn't magically become the only tech company in the world to release 1.0 of a new language version without lots of major bugs.

3. Webstart lets you specify multiple JVM versions in parallel: that means you can, for instnace, tell it to pick 1.4.1 if available, but if not to accept 1.5. Not very useful for normal people, I suspect, but it does mitigate against the version incompatibility problem *if* you know people are likely to not uninstall the old JVMs. I have very little faith in them leaving them around, so don't use it myself.

4. You shouldn't ever write a webstart for 1.4.1 etc; the same goes for most other "not quite latest" versions. 1.4.1 is so ridiculous buggy that the user MUST upgrade ASAP, unless they have a corporate desktop or similar that locks everyone on that buggy piece of ***.

...webstart for a.b.c_XX is an entirely different matter, of course. There are regression bugs in the XX releases you sometimes need to manually work around by specifying allowed XX's in your webstart. Just be grateful that webstart lets you do this!

Just forget about Webstart outside of vertical applications and this forum, ok? No amount of convincing me is going to help. I've got facts and data.

I wouldn't dream of trying to convince you

...but I'm a lot more optimistic about webstart, and a lot more confident in the network effect: if/when adoption hits the right threshold, it will be fine as a distribution medium (in the same way that Java is fine as a dev platform: still has plenty of "ARRGGH!!" stupid design mistakes that Sun refuses to fix, and plenty of bugs - but good enough that we, the devs, get a noticeably easier life and can do most of what we need to do to make profit).

The threshold unfortunately is somewhere near to "ubiquity" and even then it won't help - people do don't like the whole concept of Webstart. Even I don't like it. When I buy something I want a package I can download and backup somewhere permanently that doesn't auto-upgrade itself. It looks like everybody else likes it like that too.

Furthermore Webstart plays havoc with conversion rates precisely because of the tiny investment that people have in downloading and running something. As a shareware delivery platform, it's a disaster - converting at less than half the rate of the otherwise 100% identical embedded VM versions.

The threshold unfortunately is somewhere near to "ubiquity" and even then it won't help - people do don't like the whole concept of Webstart. Even I don't like it. When I buy something I want a package I can download and backup somewhere permanently that doesn't auto-upgrade itself.

I think it could only work in a subscription-like situation where you are constantly connected to a service.

* Improve desktop integration. Let the user choose a program group and let the desktop icon be just an option. Ideally, user's should never have to start the jws application manager, because it basically just sucks. They already have their own "application manager" (their os) that they're used to and don't need another, crappy unfinished one.

* Have an option in jnlp to always do desktop integration instead of the "do you want desktop integration?" dialog. It's just an annoying pop-up most of the time.

* Have an option in jnlp to disable auto-update. With desktop integration, this could be simply a manual action by use of an extra menu item "check for update".

* Have an option to let the user where to install the ws application, so in effect make another directory part of the jws cache.

I think using WebStart code/libraries to embed update capabilities in your game is the way to go. Have your self-contained game manage a private WebStart cache that only it uses. The embedded cache would come populated with the files for your game.

The thing I don't like about WebStart is how applications are "lost" to the user after having been launched the first time. If they don't make a shortcut on the FIRST launch then they have to go back to the web site to launch it again, because they have NO CLUE that the WebStart application exists and that it is a way to launch code they have already downloaded.

Um, except of course the mind-numbing: "We created chaos and confusion by releasing 1.3 so that the compiler produced stuff that crashe pre-1.3 JVMs. Because we're so stupid, let's do it all over again! We didn't quite get enough bad press about how crap java was last time (heck, there was a lot, but it blew over after a while; we need some more free publicity!), so let's really roll out the barrel this time".

Huh? What are you talking about?I for one found only one single issue with deploying my app on 1.5 after having developed it on 1.4.2. I found it extremely bizarre that it wasn't noticed and didn't cause a huge stink... that was the fact that toString() on XML Elements no longer produces the actual XML in Java 5! I had to convert my code to save my XML by doing an XML transformation.

That was the only issue, other than it Java 5 just worked.Upgrading from 1.2 to 1.3 and 1.3 to 1.4 I don't remember a single issue other than needing to use the -target switch on the compiler to keep the class version compatible when moving to 1.4.

I've heard that Java sound is somehow hosed in Java 5, but my code that uses it didn't have any problems. Perhaps I was just lucky.

That's not true, so I felt I had to mention the glaring exception: 1.3 and 1.5 both changed the class file format so that their classfiles crash on prior JVM's (or am I missing something here? It's bene a long while since I ran 1.5 classfiles, but IIRC they won't run on 1.4. I'll be rather embarassed if that's not the case ).

EDIT: IIRC it was a bug in Sun's 1.3 that wasn't intended, and got fixed (eventually) ?

Of course, personally I wouldn't have minded if: - they used that opportunity to make generics good and cool - they made a big song and dance about getting people to upgrade so that the world (not just a handful of java developers) knew about it (*)

(*) - if MS owned Java, you can bet your ass there'd have been an entire marketing campaign getting world + dog to upgarde to java 5, AND they would have put 50 coders onto making a so-easy-to-use-every-tech-illiterate-CEO-can-manage-it upgrade of webstart, and making sure it: - worked (in 95% of cases) - was really, really user-focussed (even if it had some nasty user-unfriendliness that could have bene better - you can be sure there'd be none of this "if you don't make a shortcut NOW then this app will disappear. HAHAHAHAAHAH!")

Of course, they'd have spent their time on that instead of on adding other features. I'm just citing it as a shining example of what Sun could have done, had they decided to make lots of people upgrade to java 5 instead of just a few.

Pretty much Webstart needs to give full control to the user, not the JVM. When you download software with it, it needs to ask you where you want to download it, and you need to be able to back it up and export it in a format that lets you copy it to other machines and import it back again. It needs to lose all the crazy language like "desktop integration" and treat a downloaded application like it's a first class install on the host; it has to ask about icons on install. It should inform users of upgrades but only download them when asked. It should have a nice user interface, with all the text antialiased and aligned correctly. It should have a considerably friendlier message when installing properly signed code. And so on.

But most importantly it should be bootstrappable! I would like to be able to link to a web service somewhere that allows me to download a JRE *if necessary* and then silently get on with downloading my application - without the user needing any JRE or Webstart installed already.

Furthermore the MIME type issue really screws up jnlp deployment. Most browsers manage to get it wrong in some way and require fiddling. Can we not simply have a Flash launcher?

<edit>Hey, didn't I suggest once that the whole team responsible for Webstart should be hung by the toenails until sorry? Well, obviously the punishment wasn't harsh enough. Foreskins next time.

We did have a thread for listing all the things wrong with webstart, it's lying around here somewhere...

Quote

...

All great stuff, as is erikd's ideas. Plus all the stuff collated in the older thread.

To be honest, if I happen to make a few million dollars at some point and not have left java behind long ago, I'd probably setup a company solely to fix up the crap that Sun peddles. This is exactly what happened 8 years ago when IBM shoved it in Sun's face: "you guys are being crap, and your execs are morons; LOOK: This is what you need to be doing with java; you're sitting on a goldmine and ignoring it", and which eventually put a fire under the collective corporate backsides @ sun, and lead to great work in the following years (Hotspot, for instance, is excellent. So is NIO, albeit undocumented ). I reckon Sun needs another good kicking up the jacksie, needs to sack a few senior execs who are fiddling whilst their bank balances swell, and replace them with guys from the dev teams who are probably even more frustrated than those of us using java, because they're denied the opportunity to fix the stuff (no budget, no marketing support, whatever)...

Quote

Furthermore the MIME type issue really screws up jnlp deployment. Most browsers manage to get it wrong in some way and require fiddling.

Correct me if I'm wrong but this works almost universally now? It's been a very long time since I've had problems with it.

Quote

<edit>Hey, didn't I suggest once that the whole team responsible for Webstart should be hung by the toenails until sorry?

Perhaps it would be fairer to say: "whoever was responsible for castrating Webstart at birth and preventing it from being finished being developed..."

Valve's Steam on-line delivery system is kind of like Webstart. It does autoupdating too. It has a nice interface and whatnot but plenty of people still hate it. So what chance do Sun have with Webstart?!

"I have never done unit testing and I don’t find it a very useful concept" - Jonathan Blow

Valve's Steam on-line delivery system is kind of like Webstart. It does autoupdating too. It has a nice interface and whatnot but plenty of people still hate it. So what chance do Sun have with Webstart?!

Apples...oranges.

People hate Steam for all sorts of reasons, none of which have any relevance to Webstart, including: - You don't own a Steam game, you (this is illegal, BTW, but no-one's sued them yet) rent it - Steam is 20 times as complex as webstart and all that extra functionality is / has been riddled with bugs in the live releases - Steam is NOT aimed at improving life for players, it's aimed at making more money for Valve; most people recognise this; a large minority of people are pissed off by the fact that they're being forced into this nasty, buggy, hard-to-use system only because it increases Valve's profits

Of course, let's put this into perspective: most people don't care and happily use Steam. I don't think your "plenty of people" is wrong, but it is a little misleading.

Oh, I have to respond to that! Yes, Half-Life 2 is excellent, but Steam still sucks. Whilst I applaud the concept of Steam, the implementation still has a long way to go.

Customised GUI? You mean the nasty olive-coloured boxes? IMHO they're ugly and out of place - they don't fit in with either the OS or the games. But oh, you can change them to ugly grey boxes through the preferences!

Query on update - since when? I'd love that feature, but have never seen it. I frequently decide I've got ten minutes to spare so boot up Steam, and then discover there's a half-hour update ahead of me, which I can't stop, can't defer, and I can't run any affected games until its done. So I go do something else instead.

I can't run Steam on system boot, because it requires access to the Internet immediately. In fact on my box it tries to log in before Windows boots the Wi-Fi - so it fails every time.

Integrated with desktop? Well, it places a shortcut on the desktop (just like WebStart) and applications you own have their own shortcuts (just like WebStart). Not sure how this differs.

The Steam/WebStart concept is a bold new way of distributing software, but they're both pretty far off being a dependable channel, in my opinion.

Once you have created your Valve dir you don't have to install the game again or even need internet access to play. You van even realocate your Valve dir somewhere else, rebuild all your icons or disable steam startup for windows that causes some problems. The ocasional problem of Steam loose your personal account info and requesting a connection can be solved by backing up the file that contains that info and copy it when necessary.

Most of the problems you mention are in the FAQ or answered in the steam forums. I certainly would like to see something similar to Steam for selling any java game i may create in the future as long as the service wasn't too much overcharged.

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