I am suprised too. I thought I had found the solution already?
Did I forget to make clear that using the context classloader solves all the problems?
When you say "context classloader" what are you referring to? The bootloader? The classpath class loader? I'm afraid I'm not following the term.
I thought using a property like net.java.games.util.plugins.nolocalnative broke the intention of the plugin mechnism because the native library (the plugin) has to be mentioned in the JNLP file.
Yep it does. I just accepted that as a limitation of JNLP distributed code, that they are going to have to have apriori knowledge of what plugins they are using. Since you need this knowledge ANYWAY to prepare the download jars, it didn't seem to me like it was making things any more limited then they already are
Taking the context classloader-approach doesn't need this. Still you have pre-install the plugin but that can now be done with an installer.
Right, and thats a great solution if the player wants to install it into his/her JRE, but I wanted to make both options still available to JNLP programs. (Install into JRE or make a part of your app.)