This module defines the Lookup which is the NetBeans way for dynamic registration and lookup of components in our modularized component system. It allows lookup and discovery of features by description of their interfaces. The classes are devided into two parts. The LookupAPI allows the discovery and the LookupSPI simplifies creation and registration of own lookup objects.
What is New (see all changes)?
- Oct 18 '19 Declare support for all source levels.
Typically
AbstractServiceProviderProcessorsubclasses declare someSourceVersionsupport, but as new JDKs are released, the declaration becomes obsolete and produces spurious warnings. The processors are typically not affected by newer Java language features.This change changes the default behaviour if NO
@SupportedSourceVersionannotation is present on subclass. From 8.40, the Processor will report@SourceVersion.latest(). - Oct 22 '14 A way to control Lookup.getDefault
One can use Lookups.execute(yourLookup, yourRunnable) to temporarily influence return value from Lookup.getDefault().
- Mar 27 '12 Easy and robust way to register named services
Meta annotation NamedServiceDefinition for those who define their own annotations that register something into Lookups.forPath registration area.
- Mar 10 '12
ProxyLookupcomputes results lazilyProxyLookup.lookupAll().iterator() is now incremental. E.g. you can use traverse part of the results without waiting for or creating all of them:
for (URLStreamHandlerFactory first : Lookup.getDefault().lookupAll(URLStreamHandlerFactory.class)) { return first; }
- Jan 15 '10 Introducing semihidden SPI
Adding SPI interface package for those who implement the NetBeans platform. This package is not shown in Javadoc as it does not form a generally available public API.
Use Cases
There is a great introduction to Lookup and its usage in its
javadoc.
For details on this topic,
together with code samples, see chapter 4,
of NetBeans Platform for Beginners
by Jason Wexbridge and Walter Nyland.
In addition to that here is
a list of frequently asked or interesting questions slowly expanding as
people ask them:
Lookup faq:
How to specify that a service in Lookup should be available only on Windows?
Q: Most of the time I specify interfaces that I want to add to the Lookup class in the layer.xml file. But, let's say I have a platform-specific interface (something on Windows only, for instance).How can I specify (in the xml, or programmatically) that this service should only be added to the Lookup if the platform is Windows? >
In general there are three ways to achieve this.-
It is possible to write a specific module and enable it only on windows. See os specific modules documentation. Then you can put a registration of your instance into your module's META-INF/services directory and it will be available only on Windows.
-
Another possibility that does not require new module, but which executes a code on startup (which may have performance implications) is to use
methodvalueattribute. Register your instance in layer usingyour-Object.instancefile as described at services documentation and in your factory method either return the instance your want ornulldepending on result of Utilities.isWindows() call. -
In some cases, the interface for which you will register an implementation permits a no-operation semantics. For example,
InstalledFileLocator.locate(...)can return a validFile, or null. You could always register anInstalledFileLocatorinstance yet disable it on non-Windows platforms (always returning null).
How shall I write an extension point for my module?
Q: I have more modules one of them providing the core functionality and few more that wish to extend it. What is the right way to do it? How does the Netbeans platform declare such extension point?
Start with declaring an extension interface in your
core module and put it into the module's public packages. Imagine
for example that the core module is in JAR file org-my-netbeans-coremodule.jar
and already contains in manifests line like
OpenIDE-Module: org.my.netbeans.coremodule/1 and wants
to display various tips of the day provided by other modules and thus defines:
package org.my.netbeans.coremodule; public interface TipsOfTheDayProvider { public String provideTipOfTheDay (); }
And in its manifest adds line
OpenIDE-Module-Public-Packages: org.my.netbeans.coremodule.*
to specify that this package contains exported API and shall be
accessible to other modules.
When the core module is about to display the tip of the day it can ask
the system for all registered instances of the TipsOfTheDayProvider,
randomly select one of them:
import java.util.Collection; import java.util.Collections; import org.openide.util.Lookup; Lookup.Result result = Lookup.getDefault ().lookup (new Lookup.Template (TipsOfTheDayProvider.class)); Collection c = result.allInstances (); Collections.shuffle (c); TipsOfTheDayProvider selected = (TipsOfTheDayProvider)c.iterator ().next ();
and then display the tip. Simple, trivial, just by the usage of
Lookup interface once
creates a registry that other modules can enhance. But such enhancing
of course requires work on the other side. Each module that would like
to register its TipsOfTheDayProvider needs to depend on the
core module - add
OpenIDE-Module-Module-Dependencies: org.my.netbeans.coremodule/1
into its manifest and write a class with its own implementation of the
provider:
package org.my.netbeans.extramodule; class ExtraTip implements TipsOfTheDayProvider { public String provideTipOfTheDay () { return "Do you know that in order to write extension point you should use Lookup?"; } }
Then, the only necessary thing is to register such class by using the
J2SE standard META-INF/services/org.my.netbeans.coremodule.TipsOfTheDayProvider
in the module JAR containing just one line:
org.my.netbeans.extramodule.ExtraTip
and your modules are now ready to communicate using your own extension point.
Exported Interfaces
This table lists all of the module exported APIs with defined stability classifications. It is generated based on answers to questions about the architecture of the module. Read them all...Group of java interfaces
|
Group of java.io.File interfaces
|
Group of systemproperty interfaces
|
Group of lookup interfaces
|
Implementation Details
Where are the sources for the module?
The sources for the module are in the NetBeans Mercurial repositories.
What do other modules need to do to declare a dependency on this one, in addition to or instead of a plain module dependency?
Nothing.
Read more about the implementation in the answers to architecture questions.