Extensibility and webstart...how?

Back to the old problem that Sun made the world’s first mainstream dynamically linked language and then people want to … dynamically discovre and load classes at link time - but java still doesn’t support this no-brainer.

I’ve met someone doiung the classic “make a new classloader, make a custom “load from file” loader in 10 lines of code, and laod classes from a user-specificed directory”. Now the question is: how the heck to do this in “Sun sanctioned” ways, i.e. so that it will work in webstart?

Off the top of my head, ideas so far are:

  1. Make all the downloadable additional classes Extensions. The author then has to manually specify every single one in the webstart JNLP for the app. Off the top of my head … I think they also have to hard-code a description of each into the app, which is incredibly stupid given what this trying to acheive

  2. Make all the dl/classes into standalone apps, that “install” themselves by wrting a child of a known Muffin. Main app scans that muffin on startup to find out what additional classes are “installed”. Not sure how it’s going to instantiate them at this point…presumably, they advertise themselves in the muffin with their JNLP URL so that the main app can trigger a webstart extension fetch. However, I’ve never tried doing an extension fetch AFTER the app has started, and given the way sun chose to desgin webstart I’m not entirely sure it’s possible?

  3. …other?

Other alternatives :

  • use a URLClassLoader and a servlet to provide class bytes : won’t work for unsigned apps, but easy to implement (sources are in the jdk samples).
  • use beanshell and java sources :wink:
  • use the JNLP Download service to flush local cache and reload new jars (that might have been bebuilt by the server meanwhile) : worth to dig a little more.

Lilian

I think the place to start is to focus on what I want users and developers writing extensions to be able to do. The basic problem is that developers will write some code and put together some resources as an extension to my game and I need to ensure that this can get to users. I am going to take it as a given that the classes and resources will be packaged into a jar file. This jar file then has to find its way onto the users system and be loaded onto the classpath (not possible as I want users to be able to add extensions after program start), or be loaded via a URLClassLoader.

I think the way I am going to do it is allow the user to specify the directory containing the skins. By default this will either be the skins directory in the program installation path (if it was installed by an installer), or the gamename/skins directory in the “user.home” directory if it is running via JWS. Users can place skins there manually, download them to there via a “skin server” from within the program, or perhaps click on a jnlp link that references the main game jnlp but also includes the skin jar as an additional resource. I have to think more about the latter one.

Regards,

Alistair

[quote]This jar file then has to find its way onto the users system and be loaded onto the classpath (not possible as I want users to be able to add extensions after program start).
[/quote]
I’m not a fan of this, but … it IS possible, using a very common technique nowadays, especially for skins: download from within the app, then popup a box saying “New skin will not take effect until you restart”.

Lots and lots of C++ apps do it these days, rather than try to dynamically load something mid-operation. Even the FPS’s have a long tradition of “new skins and mods require you to restart” - even quake3 had you specifying everything that was new as command-line args saying which files you wanted to load in.