On Thu, 28 Oct 1999, Thomas McKay wrote:
There is currently no way to unload .classes that were loaded by the
Tcl classloader. This was something I wanted to add to the 1.3 versions
of Jacl and Tcl Blend. The only real catch is I am not sure how to
expose this as a Tcl command.
Perhaps a "java::cache" command that could be used like so.
java::cache -flush
There really is no way to do a "reload" in the JVM because you
will only be able to purge a .class file if there are no active
instances of that class. So it would be impossile to reload
a java.lang.String or a tcl.lang.Interp but user loaded classes
should be able to be flushed if there are no active instances.
If you interested in helping out in this area of the design
and implementation, I would welcome your input once the 1.3
development version gets going.
later
mo
> I think you're right. If the reload feature to java::load is there, that
> would be a plus. I'll play around a little bit more with java::load too.
>
> I submitted the code snippets more for sharing purposes than to suggest that
> it should be in a Jacl release. I enjoy learning from other people's
> approaches and thought my code might spark some ideas out there. :-)
>
> > -----Original Message-----
> > From: Moses DeJong [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, October 28, 1999 11:28 AM
> > To: [EMAIL PROTECTED]
> > Subject: [Tcl Java] RE: [Tcl Java] Re: [Tcl Java] loading classes
> > dynamically as commands
> >
> >
> > On Thu, 28 Oct 1999, Thomas McKay wrote:
> >
> > > After I asked the question I had some more time to poke around
> > in the Jacl
> > > src. No, it was never a feature it just seemed natural to me
> > that it would
> > > be, though.
> >
> > Are you saying that this "autoload of commands implemented in Java"
> > feature should be added to Jacl? I am not really sure that is such
> > a good idea. I take the view the Jacl should try to do things just
> > like Tcl when possible. Having some snazzy feature that works in
> > Jacl but not Tcl (and therefore Tcl Blend), seems like a step
> > backwards.
> >
> > > I'll include some code snippets below to illustrate what I am
> > doing. This
> > > was my thought: When a user types a command, say "MyCommand,"
> > the interp
> > > first checks internally for a definition. Not finding it, it calls the
> > > unknown proc. The unknown proc attempts to resolve the name by first
> > > attempting to load a class of this name. If found, the class must, of
> > > course, be an extension of Command. If it's not or the class
> > is not found,
> > > the unknown proc then treats the command as an executable name
> > and attempts
> > > to run it. (At this point we're in the original unknown proc
> > provided with
> > > Jacl.)
> >
> > So is the point just to avoid the call to java::load? Why do you need
> > your own Java code, is there something that java::load did not do that
> > you needed. You can provide a -classpath argument to java::load.
> >
> > > This works out great, by the way. My application has a
> > interactive command
> > > line (wish-like). I've named the majority of the commands through the
> > > Extension feature. However, the user may right their own
> > commands to extend
> > > the functionality of the application. By removing the need for
> > an Extension
> > > for every Command, a class name becomes a command name.
> >
> > The other problem I have with your idea is that it would give people
> > the impression that putting classes in the default package was OK.
> > Perhaps a better approach would be to set it up so that people could
> > indicate "if a command is unknown look for an implementation of
> > the command with the package prefix X"
> >
> > So an unknown command "foo" with a package prefix "com.mo.unknown"
> > would look for a class "com.mo.unknown.foo". You could also have
> > a list of package prefixes to check for.
> >
> > The bottom line is that this seems like a feature that you might
> > want to add to your app, but I do not think everyone would want
> > it. You can define your own unknown command for your own
> > application so I would think that would be the best approach
> > to take. If you define your own unknown and then default to the
> > system unknown, your feature would work in Tcl Blend too.
> >
> > Also, you comment about being able to reload a .class file was
> > a good one. I was already planning on adding something like that
> > to the 1.3 version.
> >
> > later
> > mo
> >
> > ----------------------------------------------------------------
> > The TclJava mailing list is sponsored by Scriptics Corporation.
> > To subscribe: send mail to [EMAIL PROTECTED]
> > with the word SUBSCRIBE as the subject.
> > To unsubscribe: send mail to [EMAIL PROTECTED]
> > with the word UNSUBSCRIBE as the subject.
> > To send to the list, send email to '[EMAIL PROTECTED]'.
> >
>
> ----------------------------------------------------------------
> The TclJava mailing list is sponsored by Scriptics Corporation.
> To subscribe: send mail to [EMAIL PROTECTED]
> with the word SUBSCRIBE as the subject.
> To unsubscribe: send mail to [EMAIL PROTECTED]
> with the word UNSUBSCRIBE as the subject.
> To send to the list, send email to '[EMAIL PROTECTED]'.
>
----------------------------------------------------------------
The TclJava mailing list is sponsored by Scriptics Corporation.
To subscribe: send mail to [EMAIL PROTECTED]
with the word SUBSCRIBE as the subject.
To unsubscribe: send mail to [EMAIL PROTECTED]
with the word UNSUBSCRIBE as the subject.
To send to the list, send email to '[EMAIL PROTECTED]'.
