Ok,

I got stuck at one point here. To be clear i am giving an example below:
Lets say we have an interface X in java 5 which has a method which returns a
type Y as shown below

public interface X {
  Y a();
}

The same interface in Java 6 is, but it adds a method  named b, which
returns a type Z which is only available in java 6

public interface X {
 Y a();
 Z b();

}

Now lets say I have an existing class named XImpl

public class XImpl implements X {
  public Y a(){ return new Y();}
}

If I compile the above XImpl with Java 5, it would work fine, however the
compiler will complain in Java 6.

Using dynamic proxies would work fine at runtime in both Java 5 and Java 6.
My question is , how do i satisfy the Java 6 compiler before i run the
program to generate the dynamic proxy?

On 1/23/07, Karan Malhi <[EMAIL PROTECTED]> wrote:

Dain

Now I understand what you are saying. This is a great idea to combat this
compatibility issue

On 1/23/07, Karan Malhi < [EMAIL PROTECTED]> wrote:
>
> i made my own java.sql package and added No-Op interfaces and classe
> representing SQLClientInfoException, NClob, SQLXML. My code compiles fine,
> but if we add this package to openejb code, would that be a violation of
> some kind of java license
>
> In terms of a proxy, wouldnt you still need the interfaces for the proxy
> to implement, unless you are talking about different proxies for different
> versions of jdk resolved at runtime.  Is that what you mean by dynamic proxy
> in this scenario?
>
> On 1/23/07, Dain Sundstrom < [EMAIL PROTECTED]> wrote:
> >
> > On Jan 22, 2007, at 8:42 PM, David Blevins wrote:
> >
> > >
> > > On Jan 6, 2007, at 5:50 AM, Karan Malhi wrote:
> > >
> > >> This is the first time i have noticed it. I dont know what other
> > >> projects
> > >> do, but i think we could simply provide empty implementations of
> > the
> > >> inherited abstract methods. I can provide a quick patch for this.
> > >> The JIRA
> > >> issue is OPENEJB-435
> > >
> > > I gave this patch a shot and it fails to compile in JDK 1.5 as
> > > these classes don't exist:
> > >
> > >  import java.sql.NClob;
> > >  import java.sql.SQLClientInfoException;
> > >  import java.sql.SQLXML ;
> > >
> > > Does anyone know if there are many backport versions of these that
> > > we could use or some way to support 1.6 without breaking 1.5support?
> >
> > Alternatively, we could use a dynamic proxy.  That would have the
> > added benefit of being able to expose the vendor specific interfaces
> > in addition to all new jdbc stuff as it is added.
> >
> > -dain
> >
>
>
>
> --
> Karan Malhi
>



--
Karan Malhi




--
Karan Malhi

Reply via email to