This is the mail archive of the
kawa@sources.redhat.com
mailing list for the Kawa project.
Re: importing java packages
- From: Steve Yegge <steve dot yegge at gmail dot com>
- To: Per Bothner <per at bothner dot com>
- Cc: S D <s dot mailinglists at gmail dot com>, Chris Dean <ctdean at sokitomi dot com>, kawa at sources dot redhat dot com
- Date: Fri, 8 Apr 2005 20:53:28 -0700
- Subject: Re: importing java packages
- References: <d494cb8f050316212611846b5b@mail.gmail.com> <m2sm2uf7cj.fsf@tungsten.mercedsystems.com> <4239D582.4070607@bothner.com> <301e20f605040816564b4420ed@mail.gmail.com> <4257220A.4030203@bothner.com>
- Reply-to: Steve Yegge <steve dot yegge at gmail dot com>
FWIW, although I'm far from being a Jython expert, I've noticed that
it notices whenever a jar is added to the classpath, or the file timestamp
on a jar in the classpath changes, and it preprocesses the new jar on
startup. It caches the names of probably-instantiatable classes from
all jar files and directories in the classpath in a cache directory, for use
in import statements.
Not that this is a particularly elegant solution; it's lame that Java doesn't
provide this kind of metadata for you -- but it appears to work, since
"from <pkg> import *" works reasonably well in Jython. At least, it incurs
no detectable performance hit, except for the preprocessing that occurs
on startup when you change your classpath contents.
-steve
On Apr 8, 2005 5:30 PM, Per Bothner <per@bothner.com> wrote:
> S D wrote:
> > I was going through BeanShell documentation and found that they seem
> > to support importing of package classes in their interpreter.
> >
> > http://www.beanshell.org/manual/syntax.html#Importing_Classes_and_Packages
>
> There are two basic approaches to handling:
> import A.B.*;
>
> (1) Lazily: when you see a reference to a class X, you see if
> there exists a class A.B.X, but you don't do anything on an
> import except remember that you've seen it.
> (2) Eagerly: when you see the import, search the classpath,
> and find all classes in A.B.*.
> (3) A hybrid: See if there are any classes in A.B.X, to catch
> typos in the import, by search for names as needed.
>
> I believe JDK (at least 1.4.x) does (3) or possibly (2). It does
> catch "non-existing" packages, so it's not completely lazy.
>
> The problem is that I don't know of any convenient Java classes
> to do (2) or (3). It would mean on an import searching each
> entry on the classpath if there is such a directory. For a .jar
> file that means linearly searching through the jar directory.
> (Not the entire jar - just its directory.) It's not a lot of
> code to write (probably less than 100 lines), but it gets a
> little mor complicated if you ant to cache it.
>
> We can implement a variant of (1) more easily.
>
> It is likely that the JVM may do some caching to optimize
> such searches.
>
> I tried Package.getPackage(NAME) best it doesn't seem useful.
> --
> --Per Bothner
> per@bothner.com http://per.bothner.com/
>