This is the mail archive of the
kawa@sources.redhat.com
mailing list for the Kawa project.
Re: importing java packages
- From: Per Bothner <per at bothner dot com>
- To: S D <s dot mailinglists at gmail dot com>
- Cc: Chris Dean <ctdean at sokitomi dot com>, Steve Yegge <steve dot yegge at gmail dot com>, kawa at sources dot redhat dot com
- Date: Fri, 08 Apr 2005 17:30:02 -0700
- Subject: Re: importing java packages
- References: <d494cb8f050316212611846b5b@mail.gmail.com> <m2sm2uf7cj.fsf@tungsten.mercedsystems.com> <4239D582.4070607@bothner.com> <301e20f605040816564b4420ed@mail.gmail.com>
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/