Re: [tcljava-dev] Patch: java::import -classpath -resolve
Brought to you by:
mdejong
From: Tom P. <tpo...@ny...> - 2003-04-09 14:40:14
|
On Wed, Apr 09, 2003 at 01:14:00AM -0700, Mo DeJong wrote: > On Tue, 8 Apr 2003 22:07:41 -0600 > I must admit, I don't like the idea of adding a -classpath option to the > import command. The java::import command is meant to act like the > import statement in Java, in that it allows using a short name for > a class instead of the fully qualified name. > > What is wrong with setting the CLASSPATH or the TCL_CLASSPATH env > var before running the java::import command? I'd like to be able to specify from where to load a class in my Hyde package. I'm now using the Pizza compiler (pizzacompiler.sf.net) as an in-process compiler for Hyde. I also would like to make Hyde as 'package friendly' as possible, not distrubing global environment's CLASSPATH or TCL_CLASSPATH. With this patch, along with my previous patches to set a Jacl library path and append that path in init.tcl, I can find the pizza jar file and invoke the compiler fairly easily. > I also don't see how this -resolve flag fits in with the functionality > of the import command. In what situation would one want to > pass this -resolve flag, and in what situation would one not want > it passed? Why would we want to expose this feature at the script > level? > > I read over the JDK docs but they were not very clear on exactly what > the resolve really does. It seems one needs to read the JVM book to > find out what "the class is linked" means. It's certainly not clear to me either! In working with Hyde, importing the main class for the Pizza compiler yielded protection errors on another Pizza compiler class when specifing the pizza jar on TCL_CLASSPATH, but using the resolve flag seemed to fix those problems. Java class loading seems to be more of a black art than it needs to be. -- Tom Poindexter tpo...@ny... http://www.nyx.net/~tpoindex/ |