Note: These pages are being reviewed.
Why use this strange convention - wouldn’t a Map be good enough?
Other platforms do use string-keyed maps for this sort of thing, but there are some weaknesses with that approach:
it is impossible to enforce dependencies. With
Lookup, a module’s code cannot request an object of type X unless it can load/access the
X.class. The module trying to look up an X will not be able to see
X.classunless it declares a dependency on the module that defines X and the module which defines X says that it allows access to the Java package X lives in. (A
Map<Class<T>,T>would do the same job as
The class of values in a map can change without notice - so if you have
(SomeIface) foo = (SomeIface) globalMap.get("foo"), some new version of the module that provides "foo" can change the return type, causing
Lookup, you cannot ever get an object that is not of the type you passed in the request - so Lookup’s approach is more robust.
Lookupsupports listening to changes in the result.
Lookupsupports multiple instances for one key - if you call
lookup(X.class)you get one instance. If you call
lookupAll(X.class)you get a
Collection<? extends X>(so with
lookupAll()it is more like a
There are some other capabilities of
Lookup (such as getting the specific type or number of results without actually creating objects, and providing named result items) but these are rarely used in practice.
Lookup is very powerful, yet simple and generic; people quickly learn to love it, once they realize what it can do.
See also the javadoc: [http://bits.netbeans.org/dev/javadoc/org-openide-util-lookup/org/openide/util/Lookup.html
Apache Migration Information
The content in this page was kindly donated by Oracle Corp. to the Apache Software Foundation.
This page was exported from http://wiki.netbeans.org/DevFaqLookupVsHashmap , that was last modified by NetBeans user Tboudreau on 2010-02-18T23:58:49Z.
NOTE: This document was automatically converted to the AsciiDoc format on 2018-02-07, and needs to be reviewed.