How to separate interface from implementation when using JARs?

[MJT.Keijsers]

Hi,

In an engineering world where I used to be working with C++ I am now
shiftnig to Java. In C++ I would publishe my interfaces in header
files. In Java I can use the interface concept.
However this is not sufficient for me. I want to be able to full
separate the implementation from the interface of e.g. a class method.

Example:

public interface MyMath {

 

[Marc]

On Sep 17, 1:33 pm, (e-mail address removed) wrote a message and was too
soon to send , Full text below:

Hi,

In an engineering world where I used to be working with C++ I am now
shiftnig to Java. In C++ I would publishe my interfaces in header
files. In Java I can use the interface concept.
However this is not sufficient for me. I want to be able to full
separate the implementation from the interface of e.g. a class
method.

Example:

public interface MyMath {
int MyAdd(int a, int n);
}

class Calculate implements MyMath {
int MyAdd(int a, int n) {
return a - b;
}

I would use this class as an import in my client code:

#import Calculate

class client {
void DoIt() {
Calculate c = new Calculate();
int sum = c.MyAdd(9,7);
}


Once I discover the implementation error in the Calculate and want to
fix that I do not want to change the client code to require
recompilation/distribution. In C++ I would not have to change the
header file,only a cpp file. I would compile and link the math library
to a dll and redistribute only that DLL. In basic JAVA, when I
recompile my client code will recompile leading to a new (changed?)
client JAR which I should also redistibute. This is undesired for me.

I played with RMI and managed to do this when using two JVM's, but in
the 'simple' scenario where I want to divide a project in separate
JARs for maintainability, do I have to accept the fact that the client
code changes, or must I apply RMI?

Kind Regards,

Marc

 

[Hunter Gratzner]

Hi,

In an engineering world where I used to be working with C++ I am now
shiftnig to Java. In C++ I would publishe my interfaces in header
files. In Java I can use the interface concept.
However this is not sufficient for me.

If you want to have C++ use C++.

 

[derek]

i dont see what the problem is, just put the interface in one jar.
for example: myapi.jar
then put the implementing classes in another file mylib.jar
you could also put the classes that use both in another file myapp.jar

this is what we typically do.

 

[Patrick May]

In an engineering world where I used to be working with C++ I am
now shiftnig to Java. In C++ I would publishe my interfaces in
header files. In Java I can use the interface concept. However
this is not sufficient for me. I want to be able to full separate
the implementation from the interface of e.g. a class method.

Example:

public interface MyMath {
int MyAdd(int a, int n);
}

class Calculate implements MyMath {
int MyAdd(int a, int n) {
return a - b;
}

I would use this class as an import in my client code:

#import Calculate

class client {
void DoIt() {
Calculate c = new Calculate();
int sum = c.MyAdd(9,7);
}

Once I discover the implementation error in the Calculate and want
to fix that I do not want to change the client code to require
recompilation/distribution. In C++ I would not have to change the
header file,only a cpp file. I would compile and link the math
library to a dll and redistribute only that DLL. In basic JAVA, when
I recompile my client code will recompile leading to a new
(changed?) client JAR which I should also redistibute. This is
undesired for me.

If I understand your issue correctly, you can achieve something
similar by creating separate jar files for interfaces and
implementations. With that approach, you could release only the
implementation jar when fixing a bug.

If you have a distributed system, you could dynamically download
updates by distributing jars only to class servers. One Java
technology that supports this is Jini (http://www.jini.org).

Regards,

Patrick

 

[franco]

On Sep 17, 1:33 pm, (e-mail address removed) wrote a message and was too
soon to send , Full text below:

Hi,

In an engineering world where I used to be working with C++ I am now
shiftnig to Java. In C++ I would publishe my interfaces in header
files. In Java I can use the interface concept.
However this is not sufficient for me. I want to be able to full
separate the implementation from the interface of e.g. a class
method.

Example:

public interface MyMath {
int MyAdd(int a, int n);

}

class Calculate implements MyMath {
int MyAdd(int a, int n) {
return a - b;

}

I would use this class as an import in my client code:

#import Calculate

class client {
void DoIt() {
Calculate c = new Calculate();
int sum = c.MyAdd(9,7);

}

Once I discover the implementation error in the Calculate and want to
fix that I do not want to change the client code to require
recompilation/distribution. In C++ I would not have to change the
header file,only a cpp file. I would compile and link the math library
to a dll and redistribute only that DLL. In basic JAVA, when I
recompile my client code will recompile leading to a new (changed?)
client JAR which I should also redistibute. This is undesired for me.

I played with RMI and managed to do this when using two JVM's, but in
the 'simple' scenario where I want to divide a project in separate
JARs for maintainability, do I have to accept the fact that the client
code changes, or must I apply RMI?

Kind Regards,

Marc

I think you are confusing two functions of C/C++ world with the Java
world.

in C/C++ .h files can specify an interface and/or a namespace.
binaries compiled against the namespace can have the implementations
swapped out without recompiling.

in Java interfaces do not do this, they allow any class that
implements the interface to be used in the same code. This is
statically typed polymorphism - not what you want.

what you want to do in this case is not to make a interface and then
an implementation class, but just make a class in a specific package
and have your jar provide that.

Example:
// the main program
import org.marc.Math;
....
int x = Math.myAdd(3, 4);
....

// first revision of the class. this is in your jar
package org.marc;
class Math {
public static int myAdd(int a, int b) {
return a - b;
}
}

// the bug is found and fixed, now remake the jar with this code, and
swap out the old jar with the new one in the classpath (like the
loadpath, but for java).
package org.marc;
class Math {
public static int myAdd(int a, int b) {
return a + b;
}
}

to tie it all together, "org.marc.Math" is the "interface", but don't
use the term in Java because it already exists for another purpose.

 

[Roedy Green]

In an engineering world where I used to be working with C++ I am now
shiftnig to Java. In C++ I would publishe my interfaces in header
files. In Java I can use the interface concept.
However this is not sufficient for me. I want to be able to full
separate the implementation from the interface of e.g. a class method.

What is the limitation of Java interfaces? The equivalent of
publishing C++ H files is publishing the Javadoc.

 

[Patrick May]

What is the limitation of Java interfaces? The equivalent of
publishing C++ H files is publishing the Javadoc.

Not really. It's the equivalent of publishing the Java
interfaces without any implementing classes.

Regards,

Patrick

 

[Lew]

I think you are confusing two functions of C/C++ world with the Java
world.

in C/C++ .h files can specify an interface and/or a namespace.
binaries compiled against the namespace can have the implementations
swapped out without recompiling.

in Java interfaces do not do this, they allow any class that
implements the interface to be used in the same code. This is
statically typed polymorphism - not what you want.

what you want to do in this case is not to make a interface and then
an implementation class, but just make a class in a specific package
and have your jar provide that.

Another approach you should google is "Dependency Injection" (DI), a.k.a.
"Inversion of Control" (IOC), whereby you instantiate a class at runtime
conforming to an interface, with the implementation specified by a runtime
resource (e.g., deployment descriptor). All calls to the class are via
interface-specced methods, grabbing an instance of that implementation via a
(perhaps static) factory method that accesses the resource and delivers up a
conformant instance.

This turns out to be somewhat more flexible and powerful than the C++ header
mechanism, once you get used to thinking of it this way.