JGF feature requests/annoyances...

[moogie]

Annoyance

When ever i try uploading my game logic JAR it always gets knocked off the top posistion in the list of jars for that version. I.e. if i upload it first then upload another jar it gets moved down. I then delete the jar that caused the shunting so that the correct jar is at the top. I then re-upload the deleted jar but it still causes the shunting.

This means that the automatic JNLP file creator lists the incorrect JAR as the first JAR causing it to fail finding the main class and thus the game cannot load.

Feature requests

- add a radio check box for each JAR to nominate the Jar that should be first in the list when generating the JNLP file
  or allow game owners to edit the generated JNLP file

- Each time a version is created, users have to re-download every JAR, even if those JARs are unmodified.... so can you store the JARs on the sever in such a way as to not change the url for the jars each time a version is created, rather only change it when it is updated?

[blahblahblahh]

This means that the automatic JNLP file creator lists the incorrect JAR as the first JAR causing it to fail finding the main class and thus the game cannot load.

Specifying the main-class using the form field belwo the jar list is supposed to make this unnecessary (according to the webstart docs). That was the way Sun chose to implement it - are you saying the main-class field/tag isn't working?

EDIT: if you're merely saying you don't want the hassle of doing this then I'm right with you...

- add a radio check box for each JAR to nominate the Jar that should be first in the list when generating the JNLP file
  or allow game owners to edit the generated JNLP file

That's not a trivial change (basic SQL is poor at supporting easy custom sorts), so it's not especially likely to happen unless there's something wrong with the main-class system, or I find myself messing with that page (SQL filter + back-end processing code) for some other reason.

Personally, I consider it a bug (a shortsighted, foolish "feature") that the first jar has this special effect but no others do, but there's nothing we can do about *that*.

- Each time a version is created, users have to re-download every JAR, even if those JARs are unmodified.... so can you store the JARs on the sever in such a way as to not change the url for the jars each time a version is created, rather only change it when it is updated?

Yes, this is a nasty bug that was introduced a while back - and is one I've been wanting to get rid of personally for some time. It's a side-effect of two things:
  1. when an author changes the version, we have to keep the files independent of old copies, in case of new inadvertent bugs; versioning by directory was a very simple way of achieving this that needed no code changes at the time (and see below for why this was done, even knowing it screws up the timestamp / basic webstart protocol)
  2. Sun's basic download protocol sucks in many ways, and this is one of them: it has no way for you to tell it that its copy of file X is actually now named file Y (IIRC redirects cause it to break - but don't take my word for it, and I ought to double-check); IIRC (off the top of my head) you can't even change the codebase to have this effect, and/or changing the codebase doesn't work because you aren't allowed to use ".." syntax - one or the other, which is intensely annoying (and pretty stupid  / shortsighted).

The intended solution was to switch to using the "other" protocol that is built-in to webstart: the "version protocol". Rather than encode the version in the filename, this protocol has an extra attribute in the JNLP file (version="", unsuprisingly ) and allows the server to return whatever file it wants, including jardiffs and other exciting stuff.

However, I just heard from Mark Thornton that java 1.5 breaks the version protocol - things like webstart CD installs won't work with the version protocol.

So ... this needs more thought . Rest assured, I'm working on it, but with webstart on the server you often find that every avenue you try doesn't work because of different bugs or stupidities in Sun's webstart spec or client implementaiton. So, you have to keep on thinking up new workarounds, and testing them, in the desperate hope of finding the one that works .

Thanks for the comments; if nothing else, they help with deciding what to prioritise next

[moogie]

Specifying the main-class using the form field belwo the jar list is supposed to make this unnecessary (according to the webstart docs). That was the way Sun chose to implement it - are you saying the main-class field/tag isn't working?

EDIT: if you're merely saying you don't want the hassle of doing this then I'm right with you...

Unfortunetly no... it does look for the main class in my background JAR which only contains background images when i am using a full qualified main class for a class which is in a totally different JAR. When i download the jnlp and then manually edit the jnlp file so that the jar with the main class is at the top it all works peachy.

Personally, I consider it a bug (a shortsighted, foolish "feature") that the first jar has this special effect but no others do, but there's nothing we can do about *that*.

sight it is things like this that make little wonder why users perfer native executables...

Yes, this is a nasty bug that was introduced a while back - and is one I've been wanting to get rid of personally for some time. It's a side-effect of two things:
  1. when an author changes the version, we have to keep the files independent of old copies, in case of new inadvertent bugs; versioning by directory was a very simple way of achieving this that needed no code changes at the time (and see below for why this was done, even knowing it screws up the timestamp / basic webstart protocol)
  2. Sun's basic download protocol sucks in many ways, and this is one of them: it has no way for you to tell it that its copy of file X is actually now named file Y (IIRC redirects cause it to break - but don't take my word for it, and I ought to double-check); IIRC (off the top of my head) you can't even change the codebase to have this effect, and/or changing the codebase doesn't work because you aren't allowed to use ".." syntax - one or the other, which is intensely annoying (and pretty stupid  / shortsighted).

The intended solution was to switch to using the "other" protocol that is built-in to webstart: the "version protocol". Rather than encode the version in the filename, this protocol has an extra attribute in the JNLP file (version="", unsuprisingly ) and allows the server to return whatever file it wants, including jardiffs and other exciting stuff.

oh well i guess i will go back to how i was before and combine all the jars into one big uber jar... at least then it is garenteeed to be be first

However, I just heard from Mark Thornton that java 1.5 breaks the version protocol - things like webstart CD installs won't work with the version protocol.

So ... this needs more thought . Rest assured, I'm working on it, but with webstart on the server you often find that every avenue you try doesn't work because of different bugs or stupidities in Sun's webstart spec or client implementaiton. So, you have to keep on thinking up new workarounds, and testing them, in the desperate hope of finding the one that works .

Thanks for the comments; if nothing else, they help with deciding what to prioritise next

Games published by our own members! Check 'em out!

[swpalmer]

Personally, I consider it a bug (a shortsighted, foolish "feature") that the first jar has this special effect but no others do, but there's nothing we can do about *that*.

sight it is things like this that make little wonder why users perfer native executables...

Developers producing broken code does give Java a bad name.. but  native executables aren't the solution.  Fix the JNLP file.. sure the requirement is stupid, but it is also a trivial requirement to meet.  Move on and complain about the important things.

[moogie]

Personally, I consider it a bug (a shortsighted, foolish "feature") that the first jar has this special effect but no others do, but there's nothing we can do about *that*.

sight it is things like this that make little wonder why users perfer native executables...

Developers producing broken code does give Java a bad name.. but  native executables aren't the solution.  Fix the JNLP file.. sure the requirement is stupid, but it is also a trivial requirement to meet.  Move on and complain about the important things.

LOL!

I would love to but JGF as it is does not let me edit the JNLP file it generates....

[woogley]

- add a radio check box for each JAR to nominate the Jar that should be first in the list when generating the JNLP file
 or allow game owners to edit the generated JNLP file

That's not a trivial change (basic SQL is poor at supporting easy custom sorts)

wow, you must be using a poor  SQL implementation if custom sorting is difficult. In my experience (with MySQL, at least), using the "ORDER BY" keyword sorts pretty nicely.

Lets say you added a field to the jar table called "priority" (unsigned int or whatever). You could have the author set which priorty the JARs have via some kind of list (<select> should help with this), the lower the priority value, the higher the priority (i.e. 1 would have more priority than 3).

Then you could sort the JARs by priority with a simple SQL statement:

1	SELECT * FROM `table_of_jars` ORDER BY `priority` ASC

That would return a result set with the highest priority on top

But this is all just a guess because I don't know your SQL implementation (Postgre, mSQL, etc) and I don't know how you have your DB set up..

[blahblahblahh]

wow, you must be using a poor  SQL implementation if custom sorting is difficult. In my experience (with MySQL, at least), using the "ORDER BY" keyword sorts pretty nicely.

SQL was not designed to do non-relational stuff; this kind of sort "I want one item in one place, and everything else doesn't matter" is not a relational sort.

*Nothing* in SQL is particularly hard - even making a hierarchical XML DB only involves time and slow DB performance - but everything is relative.

For instance, editing a template file by hand (takes 3 seconds), or fixing another feature which needs to be fixed anyway (if something wrong with the main-class attribute) takes a lot less time than altering SQL, debugging it, adding unit tests, etc.

[woogley]

SQL was not designed to do non-relational stuff; this kind of sort "I want one item in one place, and everything else doesn't matter" is not a relational sort.

I wasn't implying that the rest of the JARs don't matter, that's why I added the "ASC" keyword to ensure the next highest priority JAR was next in case the user found the first JAR to be corrupted or something. If I was implying "everything else doesn't matter," I would've used "LIMIT 1" in the query

And since SQL has the lovely "LIMIT" keyword, I don't see where its not designed to single out one row of data.. but thats up to opinion I suppose

...takes a lot less time than altering SQL, debugging it, adding unit tests, etc.

Are you sure you're just not a wee bit on the lazy side A simple SQL query such as that shouldn't take any debugging and wouldn't need very many tests at all

But still, I'm not sure how your DB is setup, so I don't know how complicated it would be for you..

[blahblahblahh]

the next highest priority JAR was next in case the user found the first JAR to be corrupted or something.

would seem a great idea, but then - [people writing the webstart client] would be writing code that checked each jar in turn, and, um...well, that's what you'd expect in the first place, as the *right* way of doing it, and they already chose not to .

And since SQL has the lovely "LIMIT" keyword, I don't see where its not designed to single out one row of data.. but thats up to opinion I suppose

It doesn't really matter right now, and this isn't a reason for not doing it now, but FYI generally I want as few SQL queries as possible in this: the JNLP gets accessed rather a lot of times each time a game is played (4, usually!) and the SQL queries currently make it 4 times slower than it is with just all the logic code.

And bear in mind this is accessed EVERY time a game is started, anywhere, even if there's no web browsing going on...

Are you sure you're just not a wee bit on the lazy side A simple SQL query such as that shouldn't take any debugging and wouldn't need very many tests at all

Indeed I am sure, because there's a shed-load of stuff on the todo list, and anything that reduces that workload increases the amount that gets done. This isn't laziness, it's pragmatism .

You're lucky if "a simple SQL query" never takes "any" debugging. Since SQL has no compile-time checking (well, on JGF there's a little, but still only 50% coverage or so) any typo takes typically a fair number of minutes to discover and fix (compile, upload, restart server, navigate to relevant page, invoke SQL query, check result, find broken query in log file, go back to source, fix, recompile, and check again...).

Shrug. Obviously I'd rather be fixing things than typing this, but haven't got source access at the mo (still at work).