A
Audison.Athena
According to the JNLP Specification, the JNLP Client can support
automatic obtain of just-in-time resource through a URL which may point
to anywhere, even a resource reside in a remote machine over the
internet. This can to some extent shorten the first launching time of
an application obtain from a remote site, which need only the resource
to start the application. And during the running of the application, it
seems the JNLP Client can communicate with the application, act as an
listener. When the running application try to load some resource which
hadn't been ready locally in advance, for example, a class byte-code
file from local file system, then instead throw ClassNotFound Runtime
error, the classloader seems it could notify the JNLP Client, and then
the JNLP Client awakened by this signal, and then reinterpret the JNLP
file for the application, download the lack resource marked as lazy
from corresponding URL. And then whenever the resource in need is
ready, then it will notify the application's classloader which's
waiting for it, then the continuation will go again. Of course, the
detail progress between the jnlp client and the application are all my
imagination, not from any specification.
because I think the JNLP client itself is a standalone program which
may be running in a vm, and as a process from operating system's view.
And the application should be a standalone java program, and of course
it's a normal program and excluded from complexity code for dealing
with the case of lacking of class file resource and should throw the
ClassNotFound Error, and even if it realize such code, the URL of the
lacking resource may be hard-coded, all reading from a file, which may
not be the same of the URL in the jnlp file. So it seems if the jnlp
client and the lauched application were in two different vm, the above
protocol even if may be implemented in the jnlp client side, it's not a
duty for the launched application. Then what's the magic behind, can
anyone help me?
automatic obtain of just-in-time resource through a URL which may point
to anywhere, even a resource reside in a remote machine over the
internet. This can to some extent shorten the first launching time of
an application obtain from a remote site, which need only the resource
to start the application. And during the running of the application, it
seems the JNLP Client can communicate with the application, act as an
listener. When the running application try to load some resource which
hadn't been ready locally in advance, for example, a class byte-code
file from local file system, then instead throw ClassNotFound Runtime
error, the classloader seems it could notify the JNLP Client, and then
the JNLP Client awakened by this signal, and then reinterpret the JNLP
file for the application, download the lack resource marked as lazy
from corresponding URL. And then whenever the resource in need is
ready, then it will notify the application's classloader which's
waiting for it, then the continuation will go again. Of course, the
detail progress between the jnlp client and the application are all my
imagination, not from any specification.
because I think the JNLP client itself is a standalone program which
may be running in a vm, and as a process from operating system's view.
And the application should be a standalone java program, and of course
it's a normal program and excluded from complexity code for dealing
with the case of lacking of class file resource and should throw the
ClassNotFound Error, and even if it realize such code, the URL of the
lacking resource may be hard-coded, all reading from a file, which may
not be the same of the URL in the jnlp file. So it seems if the jnlp
client and the lauched application were in two different vm, the above
protocol even if may be implemented in the jnlp client side, it's not a
duty for the launched application. Then what's the magic behind, can
anyone help me?