I am trying to figure out the ServiceLoader of Java.
I set up a VERY basic test-implementation:
public class BaseThingy {
public BaseThingy(){
Iterator<WriteService> iter = ServiceLoader.load(WriteService.class).iterator();
while (iter.hasNext()) {
WriteService plugin = iter.next();
System.out.print(plugin.getText());
}
}}
Interface:
public interface WriteService {
String getText();}
Now, as far as I understood things, I write an implementation, and put the implementing class (with no further files or manifest??) into a jar.
The project itself requires a file: META-INF\services\experimental.plugin.WriteService
In this file, I write the full name of the implementation (in my case. that would be experimental.plugin.WriteHello).
Now, I am working within Intellij as IDE.
Where should I put the file, and where should I put the jar with the implementing class?
I am not getting any errors, but neither is ANY implementation being found.
Or does the jar-file need anything additional after all?
The META-INF/services/experimental.plugin.WriteService must be in the classpath as well as the JAR with the implementation.
Related
So I've been making some kind of plugins API for a Java project (to load JAR files externally) and well, I wanted to be able to add any Guice module inside any plugin to my project's dependency graph.
What I did was have a PluginsModule and in the configure method scan for other modules in plugins and install them using Java's ServiceLoader.
I made a test plugin and made a module for it, I confirmed it did get installed. No problems at this point. The problems appear when I do anything inside that module, for example I bound some interface to an implementation in that plugin (just to clear this up, I did the same thing without the plugin and it worked so it's not a binding problem) and tried to inject it, configuration errors saying there was no implementation for that interface appear.
public enum StandardGuiceModuleScanningStrategy implements GuiceModuleScanningStrategy {
INSTANCE;
#Override
public Set<Module> scan(Path directory) throws IOException {
File directoryAsFile = directory.toFile();
File[] childrenFiles = directoryAsFile.listFiles();
if (!directoryAsFile.isDirectory()
|| childrenFiles == null
|| childrenFiles.length == 0) {
return Collections.emptySet();
}
Set<Module> modules = new HashSet<>();
for (File childrenFile : childrenFiles) {
ClassLoader directoryClassLoader = new URLClassLoader(
new URL[]{childrenFile.toURI().toURL()});
ServiceLoader<Module> moduleServiceLoader = ServiceLoader.load(
Module.class, directoryClassLoader);
moduleServiceLoader.forEach(modules::add);
}
return modules;
}
In that implementation of my GuiceModuleScanningStrategy, as I mentioned before, I did use ServiceLoader. Anyways, I also tried other stuff, like scanning the JAR file and checking for a Module, and seeing if it has a specific annotation.
All Guice Modules annotated with #GuiceModule, will be installed into a child Injector. All classes annotated with #AutoBind will be bound to all inherited interfaces. You can also name it, which would lead to a named binding and overwrite the interfaces, which should be used. And if you don't want to use all Features, just overwrite the StartupModule and bind only the Features you want or your own.
I'm developing an android test app and i'm going to access all internal class of android.view package. android.view is a package that is present in jar file. I tried by loading package name but it doesn't display the classes if any one tried
this already, please help.
Here's what I tried so far:
public static void main() throws ClassNotFoundException{
Class o =Class.forName("android.view");
Class[] C=o.getDeclaredClasses();
for(int i=0;i<C.length;i++) {
Classname = C[i].getName();
ClassesDisplayActivity.your_array_list3.add(Classname);
Log.i("Ramu","classname "+ C[i].getName());
}
}
}
It is not possible to determine at runtime all of the classes that are in a package using a standard class loader.
You might have some luck with this library though:
https://code.google.com/p/reflections/
Package is not a class. You cannot call Class.forName() for package and access classes that belong to class using getDelcaredClasses().
I do not know what do you really need, so I'd recommend you to explain this in separate question. probably you will receive better solutions.
However if you really need this you have to do the following:
Get your classpath by calling System.getProperty(java.class.path)
split this property to its elements by colon
iterate over the list and read each resource. If resource is jar you can use ZipInputStream, if it is a directory use File class.
filter list of resources you got at #3.
Fortunately you can use 3rd party library named Reflections that helps you to do all this without writing code.
I have downloaded a huge project written in Java. I wish to know the Classes and Methods of every class that are available in the project (for further analysis). How can I recover this information. Can I try javadoc in eclipse?
I guess you may ask about changing SVN properties.
Follow this step if that so.
press Alt + Shift + Q
Select Show view (view : Outline)
then under that u can see all details
I have wrote a custom doclet to list the classname and its methods:
public class ListClassAndMethods {
public static boolean start(RootDoc root) {
ClassDoc[] classes = root.classes();
for(ClassDoc clazz : classes){
System.out.println("Class Name: "+clazz);
System.out.println("--------------------------");
for(MethodDoc methodz :clazz.methods()){
System.out.println(methodz.name());
}
}
return true;
}
}
you need to run create a jar of this class and refer it while creating
a javadoc using Eclipse IDE
I would extract all the class source files (.java) with find (if you're on a *nix implementation) and create an empty NetBeans project with just one package and all the classess inside it. Netbeans will correct the package declaration and you can easily use autogenerate javadoc to get a navigable web archive listing all the classes and public/protected methods.
Of course the code may not run anymore but you'll get what you want in minutes.
I wanted to add a system of adding more "commands" to my program from out side of it.
Basically, a folder that would be in the same directory as my jar (executable) that can have a varying number of "extensions"
Each "extension" would be a .class file that extends a certain abstract class that has methods defined for identification, etc.
However, I can't seem to find out if it's even possible to control these .class files from outside my main package.
Is this possible? If so how? And if not is there an alternative I could try?
Thanks!
As far as I understand you. You want to build a plugin system.
If so you should think about the java service provider approach.
In this approach you define a service provider interface (SPI) in your main
package and use the java META-INF/services location to lookup implementations.
In this case you can add extensions just by putting a jar file on the classpath.
As of java 1.6 you can use java.util.ServiceLoader.
Or you take a look at apache discovery
http://commons.apache.org/proper/commons-discovery/apidocs/org/apache/commons/discovery/tools/Service.html.
It's more powerful than the java.util.SerivceLoader since it lets you pass constructor arguments the the services it instantiates.
A possible plugin loader implementation could look like:
public interface ServiceInterface {
}
public class PluginHost {
public ServiceLoader<ServiceInterface> loadPlugins() {
File[] pluginLibraries = getPluginLibraries();
URL[] pluginLibUrls = new URL[pluginLibraries.length];
for (int i = 0; i < pluginLibUrls.length; i++) {
try {
pluginLibUrls[i] = pluginLibraries[i].toURI().toURL();
} catch (MalformedURLException e) {
throw new IllegalStateException("Unable to load plugin: "
+ pluginLibraries[i], e);
}
}
URLClassLoader pluginsClassLoader = new URLClassLoader(pluginLibUrls,
ServiceInterface.class.getClassLoader());
ServiceLoader<ServiceInterface> serviceLoader = ServiceLoader.load(
ServiceInterface.class, pluginsClassLoader);
return serviceLoader;
}
private File[] getPluginLibraries() {
// please implement
}
}
It's possible.
Jars are just zipped class files.
As long as the class files are in the classpath you're fine.
Unzip a jar file (rename from .jar to .zip and unzip) to see what the directory structure should be for the java packages.
Sure you can load a class at runtime and create a Class object also:
See this Class#forName(String, boolean, ClassLoader) API:
See this tutorial for examples.
For a simple extension mechanism have a look at ServiceLoader.
For a more complete extension mechanism have a look at OSGi.
I have written this project and already use it in other libraries of mine.
However, I find something amiss. Namely, in each user of this library, I create a utility class whose only role is to provide one or more MessageBundles. And this sucks.
I'd like to have, built into the library, a mechanism in order to have library users be able to register/recall bundles.
My first idea would be to have a singleton factory with a .register() and .get() method (with appropriate checks for duplicate keys etc) and call these from within static initialization blocks...
... But there is a problem: there is no guarantee as to which static initialization block will be called first.
Knowing that I'd like to keep the dependencies of this library "intact" (which is to mean, no external dependency at all), what solution would you recommend?
(note: this is Java 6+)
You could use the standard support for service providers: ServiceLoader. You would simply require each user of your library to provide an implementation of some interface, for example
public interface MessageBundleProvider {
List<MessageBundle> getBundles();
}
The name of the class implementing this interface would have to be specified in a file of the jar file of the user library named META-INF/services/com.example.MessageBundleProvider.
At runtime, your library would automatically discover all the message bundle providers using the following code:
private static final ServiceLoader<MessageBundleProvider> LOADER
= ServiceLoader.load(MessageBundleProvider.class);
private static final List<MessageBundle> BUNDLES;
static {
BUNDLES = new ArrayList<MessageBundle>();
for (MessageBundleProvider provider : loader) {
for (MessageBundle bundle : provider.getBundles()) {
BUNDLES.add(bundle);
}
}
}
Disclaimer: I know that ServiceLoader exists, but I've never used it before. It's how all the standard Java service providers are discovered, though (like JDBC drivers, charset providers, etc.).