API vs Impl (compile time and runtime)

[Julien Martin]

Hello,

I am building an application and I would like to have an api jar (used at compile time) and an impl jar (used at runtime) as you get with most java apis. (One api.jar containing the interfaces and one impl.jar containing the classes).

Can anyone give me a skeleton for that please? How can I design the app so that interfaces are used at compile time and classes at runtime?

Thanks in advance,

Julien Martin.

[Stan James]

Very cool question! Well, one of my favorite topics, anyhow. I got so excited when I first grokked this stuff I wrote THIS about it.

Building jars from package structures is pretty mechanical. With ANT or your IDE or even by hand you select which directories you build into which jar. Frankly I've only done it with ANT. How do you plan to build your deployments?

Putting interfaces in one jar and implementation in another jar is neat when the implementations might change. One part of your system declares stable interfaces that other parts must implement to play along. This is how you build plug-in behavior. Think about how Sun defined the JDBC interfaces in the Java libraries and different database vendors wrote implementations. You can plug Oracle or DB2 or MySQL or many others into your application because they all wrote to the interfaces. (Not the interfaces we use to write apps ... there is another set that driver writers must use.)

So the steps: 1) Write interfaces in the stable component, 2) Write implementation in pluggable components, 3) Build a jar per component, and 4) set the classpath to include the jars at runtime.

I don't know if that answered your question because it actually seemed like you had it down pretty well. Let us know if you have specific problems getting it all built.

(BTW: Some might debate jar == group of packages == component. It certainly doesn't have to, but it works ok with this definition of component.)
[ March 05, 2005: Message edited by: Stan James ]

[James Carman]

If you're looking to structure your application this way, you might want to check out HiveMind. It allows you to set up your system using "pluggable" modules that are dynamically "discovered" at runtime.

[Stan James]

James, your note about discovery points out a step I omitted above. Your program has to somehow get hooked up to real implementation classes. I've grown fond of an "application assembler" component doing "dependency injection". Fancy words you can google on and find more details, but the idea is dead simple. Read classnames for implementation classes from configuration at runtime and "push" the information into the classes that need it. For example, this sets a singleton DataStore instance in the DataStoreFactory:

String className = configuration.get("datastore");
IDataStore datastore = class.forName(className).newInstance();
DataStoreFactory.setInstance( datastore );

Variations might read all subdirectories under the plug-in directory like Eclipse, or save the class names instead of instances.

I don't know HiveMind ... does it do something like that? My understanding of Spring is that it assembles components this way, too.