On Jan 23, 2007, at 9:10 AM, Karan Malhi wrote:
OpenEJB
public interface OurX {
Y a();
}
public class OurXImpl {
Y a() { return doSomething(); }
}
The problem with the above approach is that there is existing code
like
belowpublic X getXImpl(){
return new OurXImpl(); // this would not compile because
OurXImpl is a
OurX, but not a X
}
That would be a PITA to code around.
Dynamic proxy 1.5 {
public class Ximpl implements X {
private final OurXImpl x;
Y a() { return x.a(); }
}
Dynamic proxy 1.6 {
public class Ximpl implements X {
private final OurXImpl x;
Y a() { return x.a(); }
Z b() { throw new UnsupportedOperationException(); }
}
If we are okay with providing two different impls for 1.5 and 1.6,
then do
we need a dynamic proxy for it?
Those examples were supposed to show what the generated class would be.
This should work. Alternatively, we could, as David suggested, try
to ship our own version of the missing javax.sql classes. I'm not
sure what is easiest.
I tried this and this was the easiest to do. But I am not sure of the
licensing issues i.e are we allowed to specify fully qualified
Class names
which match class names in JDK?
It should be ok, since if we are on java6 the vm classes will always
be loaded since they are in the bootstrap class loader. I say we
should just take this path.
-dain
