Take the 2-minute tour ×

I'm currently working on a Java project where I have a set of data which I wish to output in several custom formats. I have a class for each format, which takes the raw data and converts it accordingly. However, to begin with I am only implementing two or three of these formats, but wish to allow more formats to be added at a later date without having to do a massive rebuild of the application.

My idea was to create a DLL for each of the format classes, and have my application pass the data to be converted to each of these. This way, I can create a DLL later on and have my main application accessing it. (I would gladly listen to any alternative ways of doing this, as someone who has done this in C++/C# before this felt like the logical solution but it may not be applicable to Java)

My problem is that I have absolutely no idea how to do this - in C++/C# I could write this in a few lines of code but I'm not sure how it works with Java. At the risk of asking a terribly vague question, how can I do this?

Answers are greatly appreciated and cookies and tea will be offered. :)

Thanks in advance, M

Edit: Sorry, just to add: I am also unsure how to create the DLL, which must be in Java for this project, to be read in the first place. Thanks. :)

share|improve this question
add comment

6 Answers

up vote 5 down vote accepted

Rather than using a DLL per se, it seems like what is wanted is a plugin architecture of some sort.

One reason why I wouldn't recommend using a DLL unless it is necessary is that linking Java code with native code will require using the Java Native Interface (JNI) which would probably require more effort than a pure Java solution.

One relatively simple way to do so is to use the reflection capabilities of Java.

From the information given, I would probably go along the lines of the following:

  1. Define an interface for the output format.
  2. Create a Java class implementing the interface.
  3. Have the class available from the classpath.
  4. Dynamically load the class using reflection. (Using the Class.newInstance method can instantiate objects from class files loaded by the ClassLoader.)

With these steps, it would be possible to implement a simplistic plugin which wouldn't require a full rebuild when support for a new format is required.

Step 1: Define the interface

Let's say we end up with an interface like the following:

public interface Outputter {
  public void write(Data d);

Step 2: Make an implementation class

Then, we'll make an implementation class.

public class TextOutputter {
  public void write(Data d) {
    // ... output data to text

Then, compiling the above, we'll end up with a class file called TextOutputter.class.

Step 3: Make the class available from the classpath

When running the main application, we'll need to have the above TextOutputter.class in the classpath. Normally, one would tell the JVM a list of places to consider as the classpath, and that should include the above class file.

Once that is done, we should be able to load the above class using reflection.

Step 4: Dynamically load the class using reflection

Now, when we actually want to load the above class, we'd do something like the following:

// Note: We load the class by specifying the fully-qualified class name!
Class<?> clazz = Class.forName("TextOutputter");

// Then, we instantiate the class.
// Note that the following method will call the no-argument constructor.
Outputter outputter = clazz.newInstance();      

// Now, we can give data to the TextOutputter object that we loaded dynamically.

The Class.forName method is used to attempt to find the TextOutputter class from the default ClassLoader. Once we obtain the class as a Class representation, we can then instantiate an object of that class.

Instantiating the object can be performed by using the Class.newInstance method. If something other than the no-argument constructor should be used, the Constructor of the class would have to be obtained proceed to instantiate the object from there.

The object instantiates via reflection is then placed into a Outputter variable, so the write method can be called on the TextOutputter.

Adding more formats would entail the above process, but changing the fully-qualified class name (e.g. for String, the FQCN is java.lang.String) is all that is needed to load up a different class.

In a nutshell, that's what it will take to dynamically load class files and use it from your application.

(Just as a side note, I did not actually compile the above code, so there may be some errors here and there, but I hope I could illustrate the process it will take.)

share|improve this answer
yes, this works unless you want to use classes that need JNI & dynamic native libraries (for high performance or specific external libraries with POJOs used as wrappers). Since you cannot reload DLL bound classes with standard classloader, you need to subclass it in that case. –  dweeves Jan 5 '11 at 17:44
one additional note, in newer versions of java, you can use the service provider mechanism (java.util.ServiceProvider) to standardize the loading of the plugin implementations from the plugin jars. –  jtahlborn Jan 5 '11 at 17:47
@dweeves: you don't need to subclass the classloader. you just need to use a separate classloader and discard it when you want to unload the dll. –  jtahlborn Jan 5 '11 at 17:48
Thank you very much to everyone who has posted, it's been very interesting and useful to look at the different ways of doing this. I'd really like to thank Coobird for the time you've spent developing this answer, I don't think I could ask for anything more than what you've given and I really do appreciate it. I'll give this a try when I get into the office tomorrow and hopefully this will work. Thanks again, I owe you a pint. –  Myn Jan 5 '11 at 21:22
@Myn, glad I could help out :) –  coobird Jan 8 '11 at 6:11
add comment

Java SE 6 introduces the ServiceLoader class: http://download.oracle.com/javase/6/docs/api/java/util/ServiceLoader.html

If you want a proper modular approach consider the NetBeans Platform (especially if it is a desktop application) or OSGi.

share|improve this answer
add comment

I think you can ignore the JNI path. I have the impression you're using the term dll for lack of a better word, you don't really need a dll.

You could do the same thing in Java, but you'd put your filters in jar files instead of dll.

  1. Define an interface for the file format filters to implement
  2. Put each implementation into a jar, in a specific folder (like 'filters')
  3. At one point in the app, iterate over the folder, generate classloader for the jars
  4. Use reflection to find all implementations of your interface, and create a class for each
  5. Call the methods to do their job

That's basically it.

share|improve this answer
add comment

If you want write native codes (compiled to a DLL) to be used in java, you want to look at Java Native Interface (JNI).

Update you can use System.loadLibrary(String libName) (if you know the library name and the library path is set) or System.load(String filename) (library filename) to load library (DLL) in java.

share|improve this answer
add comment

I've made such things. i created an open java based plugin architecture POJO based,that even did reload on the fly of updated plugin classes. JNI is the interface for dealing with native code. The only technical part was to rewrite a classloader that enabled DLL reloading dynamically at runtime. But if you do only make "offline" updates, no such things are needed.

share|improve this answer
add comment

You can load a new DLL at any time with System.loadLibrary(). However you may need to load a java class for it to bind to.

You might find using an OSGi container helpful as this supports both load and unloading of modules (including shared libraries)

I would suggest using karaf with iPOJO but there are many others.

share|improve this answer
add comment

Your Answer


