http://www.theserverside.com/news/thread.tss?thread_id=34578
Obvioulsy this is a problem, is this the right solution?
Is it?
Will Sun be splitting up RT.jar? It has been one of my long standing RFE’s. I hope so but since the JSR is in its very early stages there won’t be anything to show for some time.
Yes.
“Replace” is probably the wrong thing to do… complement would be more sensible. Especially all that bollocks about extensions and the endorsed override wotsit that no-one understands. And rt.jar too.
Cas 
It sounds like its just another reason to bloat the distribution sizes 
It sounds like people have got this weird problem that doesn’t really exist more like. The more I think about it the more I wonder “what was wrong with jnlp?”
Cas
cas…its half one in the morning…GO TO SLEEEEP! You gaming machine!
DP
Indeed, that is the question that has to be answered before any time is spent on this JSR (not that it will be, of course - after the stupidity of Generics I’m betting JNLP will probably be swept under the carpet / wheel re-invented with new bugs as this thing :P).
Re: problem that doesn’t exist any more - actually, it very much does exist: if you’ve experience with e.g. Debian and Aptitude you’ll have seen what a “moderately good” module versioning + deployment system looks like (no, it isn’t perfect, yes there are much better ones in existence! But Debian’s is one of the best of the few that are actually in common usage instead of e.g. private proprietary systems).
Essentially, it is imperative that “the file you are delivering over the wire” contains all its own versioning, dependency, installation code, uninstall code, URL’s to external packages related to it, URL’s to other files that contain test scripts that will run against it to perform Unit testing, etc etc etc.
JNLP does not provide this. JNLP is a nice way to specify the APPLICATION requirements - what is still needed is a way to specify the MODULE requirements. If this is not immediately obvious, think of deploying server-side apps: you want to FTP a couple of files into place, you don’t want to setup a compelte webstart install, and an X-windows system (until Sun makes an ncurses version of Webstart client!) and then muck about grabbing webstart stuff.
JNLP goes a long way to making up for this by having nested JNLP’s (any extension can include other extensions ad infinitum) - but think what a nightmare it is when that nesting goes wrong, and one of the links is missing: you no longer no what you’re missing, why, and the JNLP probably came from a 3rd party website nothing to do with the app developer nor the user/player :(. And there’ll be no way of getting any information to see what it is or why you wanted it other than manually inspecting each JNLP and following every link by hand.
Of course, Sun’s implementation of JNLP still leaves many problems unsolved that it SHOULD have solved, but which doing this properly would solve instead: for instance, the inability to “lock” an installed application to a particular version, or to click a dropdown box and choose which version of a JNLP’d app you wanted to run today. All that COULD have been done in JNLP, if Sun had had the smarts to put more resource into it, AFAICS. :(.
That’s a problem that simply doesn’t exist. You’d be insane to rely on anyone else for deployment. When you deploy software, you take a precisely configured collection of binaries and supply them. No-one else should be involved. It’s just so not rocket science.
Once upon a time we were worried about bandwidth and disk space but these days? I mean c’mon, don’t pull my leg here! It’s like that old fashioned “DLL hell” - a problem that simply does not need to exist.
Cas
For instance, we’re working at the moment on infrastructure to support an almost entirely dynamic website fielding 1 billion hits per day at peak.
This involves software from 6 or 7 vendors already, with possibly up to another 10 more needing to be added to support particular features. The software modules and daemons connect to each other via at least 6 different interfaces (some API’s, some network protocols, etc), and are written in four different programming languages. Much of the interconnect is proprietary, and several of the daemons as well - all proprietary to our team.
Great, fine. In java alone we have probably 20 odd modules that are all versioned independently, and updates to which (including emergency fixes and co-versioned updates - i.e. sets of modules that need to run at particular sets of versions) are performed by approximately 6 different groups, largely in-parallel.
“just supplying all the binaries in one particular version of each” is simply not realistic: at the end of the day, on a site that changes only once every six months, yes that’s what you deliver. But during development (bearing in mind you have internal test servers, semi-public staging servers, etc - all of which with different people deploying to and needing version management etc) you need much finer grained control - and on a system like ours where we may typically be patching live servers several times a week forever, you can’t work that way.
Apologies if all you were thinking about was single-player games, whereas I approached it from the general java angle, but similar problems apply to online games anyway
When not writing games I do the serious stuff and I have to say that we simply don’t have this problem because we understand from the outset that this needs to be addressed in a different manner.
In other words, we lockdown everything before we start, and it stays that way until we lockdown everything again.
Cas
Sure, but the problem is there because you can’t always “address in a different manner”?
…except for the two situations related above: during development, and situations where lockdown simply isn’t an option.
For instance, we often have to go from RFE to deployment in under 3 hours - that includes creating a spec, development, testing, deployment to live site. It’s not pretty, but it’s an absolute requirement imposed by the business :(.
Our live patching works on a turnaround measured in minutes, because when problems occur they have to be fixed very very fast - and most of these “problems” aren’t bugs in the code or spec but content bugs (that require some tech changes to make up for) or things that have become incorrect due to outside influences :(.
Well - you’ve made your own bed, so lie in it - but don’t inflict it on the rest of us! The rest of us, who do things in a more simple traditional sort of way, would prefer it to be kept extremely simple - which it is, at the moment.
Cas
Yes, for those of us that write/support large numbers of J2EE applications with rapidly changing requirements using hundreds of different jars from many different vendors and open source projects.
Great I have some extensions for jar portable executable files, so perhaps I should try to force its update, and ECMA standardization. Should I fill JSR?
Until then this link would be something required to read. http://java.sun.com/j2se/1.3/docs/guide/extensions/versioning.html
Of course jar should be improved, because it doesn’t handle too well linear executables, but even higher care should be done by authors of libraries and programs. Namely in a field of a documentation and a versioning.
And when we are in the documentation… Where is documentation to JOGL? That mystery documentation with nice description of each method of OGL interface?
Powerful and correct is not mutually exclusive with simple!
At the moment it is not “simple” it’s just “absent”