Agreed, backward compatibility is not a valid objection, but backward
functionality should be? could be?
Your proposal sounds like a good idea.
> -----Original Message-----
> From: Mo DeJong [mailto:[EMAIL PROTECTED]]
> Sent: Thursday, March 02, 2000 6:04 PM
> To: [EMAIL PROTECTED]
> Subject: [Tcl Java] Re: [Tcl Java] External classloader for JACL
>
>
> Perhaps I was not being clear. I am proposing two changes.
>
> 1. Remove the "search for .zip and .jar files" on env(TCL_CLASSPATH)
> feature. The fact that a use might accidently get .class files
> from a .jar or .zip file is just plain wrong.
> 2. Make a new env var called env(TCL_JARPATH) which is a list of
> directories that will be searched for jar and zip files.
>
> So to sum up, env(TCL_CLASSPATH) would no longer be searched for jars
> and only the directories listed in env(TCL_JARPATH) would be searched.
> Of course, if you wanted to put the full path name of a .jar file on
> the env(TCL_CLASSPATH) that would still be supported. Does anyone
> see a problem with that? This would be going into 1.3 so
> backward compatibility is not a valid objection.
>
> Mo Dejong
> Red Hat Inc.
>
> On Thu, 2 Mar 2000, Thomas McKay wrote:
>
> > I actually like the feature of looking for and loading classes
> from the jar
> > files. As long as I can still do this through an alternative
> method (such
> > as TCL_CLASSPATH) it'll work. I can see the benefit of such a system.
> >
> > > -----Original Message-----
> > > From: Mo DeJong [mailto:[EMAIL PROTECTED]]
> > > Sent: Thursday, March 02, 2000 4:06 PM
> > > To: [EMAIL PROTECTED]
> > > Subject: [Tcl Java] Re: [Tcl Java] External classloader for JACL
> > >
> > >
> > > Both Jacl and Tcl Blend already use a class loader called
> TclClassLoader.
> > > Is there a feature that you would like to add added to the
> TclClassLoader
> > > or are you looking to bypass it completely? I do not really
> see anything
> > > wrong with adding something to the TclClassLoader or replacing it
> > > completely with something better. I really do not like the
> current design
> > > because as a programmer, you need to use the TclClassLoader
> explicitly,
> > > when this type of thing really should be done behind the scenes. I was
> > > also planning on stripping out the "feature" of the Tcl Class
> Loader that
> > > automatically looks inside .jar and .zip files that appear on the
> > > env(TCL_CLASSPATH). This makes the "worst case" lookup time depend on
> > > the number of .zip or .jar files on the file system, which is really
> > > ugly. Perhaps we should add a env(TCL_JARPATH) var instead?
> > >
> > > Mo Dejong
> > > Red Hat Inc.
> > >
> > > On Thu, 2 Mar 2000, Vladimir Zamiatin wrote:
> > >
> > > > Hello!
> > > >
> > > > I'm using JACL in web environment. I wrote engine
> > > > similar to JSP, which allows to embed Tcl scripts
> > > > in HTML pages. I want to make use of an
> > > > advanced classloader, provided by servlet runner
> > > > which has possibility to check for modification
> > > > of class or source java files in web-applications,
> > > > and recompile/reload them on-the-fly.
> > > >
> > > > I suppose one essential feature is missing in JACL:
> > > > an ability to use external class loader in interp.
> > > > It would be an easy change to add this feature to
> > > > JACL:
> > > >
> > > > Interp.setClassLoader(ClassLoader loader);
> > > > Interp.getClassLoader();
> > > >
> > > > And TclClassLoader can use this loader (if
> > > > present in Interp) to load classes. For
> > > > performance reasons it would be great if
> > > > this external loader has priority upon standard
> > > > class loading mechanisms.
> > > >
> > > > I beleive that this feature will improve
> > > > JACL ability to be embeded into different
> > > > applications and environments.
> > > >
> > > > Best regards,
> > > > Vladimir.
> > >
> > >
> > > ----------------------------------------------------------------
> > > 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]'.
> > > An archive is available at
> > > http://www.mail-archive.com/tcljava@scriptics.com
> > >
> >
> >
>
> ----------------------------------------------------------------
> 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]'.
> An archive is available at
> http://www.mail-archive.com/tcljava@scriptics.com
>
----------------------------------------------------------------
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]'.
An archive is available at http://www.mail-archive.com/tcljava@scriptics.com
