Compatibility between methods returning different types

[Ted Yu]

Hi,
I am looking for a way for the following methods to co-exist in the same class:

  public void setValue(byte[] key, byte[] value) {
  public HColumnDescriptor setValue(byte[] key, byte[] value) {

The background is that in recent release, method signature was changed from first form to second form. I am trying to maintain binary compatibility for the clients which were compiled against first form.
The above code doesn't compile. If the parameter type were int, I can introduce a new method with same name and Integer type parameter.

Maybe expert on this forum can give me some advice.

Thanks

[Dennis Sosnoski]

That's either an ingenious or a really ugly idea, depending on how you
want to look at it. :-)

But I don't think it would do you any good in this case. To use this
kludg^H^H^H^H^H elegant workaround for the limitations of the Java
language and compiler you'd need to have at least the void return method
call working off an interface reference, rather than the reference to
the implementation class. Given your original problem description I
don't see how that could work... the existing compiled code will be
going direct to the class.

AFAIK there's also no guarantee that this approach will be compatible
with future versions of the Java runtime. I don't think it's likely to
be a problem, but I wouldn't want to bet one of my projects on that.

- Dennis

Thanks for the quick response, Dennis.
For ASM, it is not Apache license.
http://today.java.net/pub/a/today/2008/07/31/return-type-based-method-overloading.html#is-this-useful
And got the idea in my previous email.
Basically change of return type can be accommodated by introducing two
interfaces. One for rev-1 method signatures, one for rev-2 method
signatures. There is one to one correspondence between the methods in
the two interfaces.
New implementation would implement both interfaces, using the
technique shown above.
I know this is not beautiful but it should work.
Cheers
------------------------------------------------------------------------
*Sent:* Friday, April 5, 2013 9:19 PM
*Subject:* Re: [seajug] Compatibility between methods returning
different types
Hi Ted,
AFAIK that should work without a problem.
The difficulty with the method return type change is that the method
signatures (including return type) are actually included in the
referencing class - so if the return type has changed the method will
no longer be found and the classloader will report an error. Change a
class's inheritance won't break anything in and of itself (as long as
the same methods are available) because that inheritance structure is
not in the binary class files.
If you want to try modifying class files your best bet is probably to
use ASM: http://asm.ow2.org/
- Dennis

Here is another question.
public class A {
public void a(int i) {
}
}
Client compiles against above code.
public interface B {
public void a(int i);
}
public class A implements B {
public void a(int i) {
}
}
Now without re-compilation, would the client jar generated earlier
still run on top of new jar with the new class A ?
Thanks
------------------------------------------------------------------------
*Sent:* Friday, April 5, 2013 6:46 PM
*Subject:* Re: [seajug] Compatibility between methods returning
different types
http://jasmin.sourceforge.net/
I also found http://www.eg.bucknell.edu/~cs360/java-assembler/
I wonder if anyone knows of other, more recent assembler(s).
Thanks
------------------------------------------------------------------------
*Sent:* Friday, April 5, 2013 8:09 AM
*Subject:* Re: [seajug] Compatibility between methods returning
different types
Thanks for the pointer.
In hindsight, new method name should have been used.
The change was done by a friend who no longer actively works on the
(open-source) project.
------------------------------------------------------------------------
*Sent:* Friday, April 5, 2013 7:34 AM
*Subject:* Re: [seajug] Compatibility between methods returning
different types
You are trying to break the overloading rule.
There is no way to have two methods with the same name and same
arguments by changing only the return type. The compiler will complain.
However, if this back compatibility is such a strong requirement, you
can always manipulate bytecodes, as described in
http://today.java.net/pub/a/today/2008/07/31/return-type-based-method-overloading.html
I did not try that and I will never do.
I would rather change the name of the method or just add another
argument.
Never forget that the person maintaining your code is a violent
psychopath who knows where you live.
Hi,
public void setValue(byte[] key, byte[] value) {
public HColumnDescriptor setValue(byte[] key, byte[] value) {
The background is that in recent release, method signature was
changed from first form to second form. I am trying to maintain
binary compatibility for the clients which were compiled against
first form.
The above code doesn't compile. If the parameter type were int, I
can introduce a new method with same name and Integer type parameter.
Maybe expert on this forum can give me some advice.
Thanks

[Ted Yu]

bq. this approach will be compatible with future versions of the Java runtime

I thought of the this aspect as well.

So far this has been an exercise that taught me several things.

I appreciate the feedback I got from this group.


________________________________
From: Dennis Sosnoski <dms-WAiJhE/vqclWk0Htik3J/***@public.gmane.org>
To: seajug-***@public.gmane.org
Sent: Saturday, April 6, 2013 2:29 AM
Subject: Re: [seajug] Compatibility between methods returning different types


 
That's either an ingenious or a really ugly idea, depending on how you want to look at it. :-)

But I don't think it would do you any good in this case. To use this
kludg^H^H^H^H^H elegant workaround for the limitations of the Java
language and compiler you'd need to have at least the void return
method call working off an interface reference, rather than the
reference to the implementation class. Given your original problem
description I don't see how that could work... the existing compiled
code will be going direct to the class.

AFAIK there's also no guarantee that this approach will be
compatible with future versions of the Java runtime. I don't think
it's likely to be a problem, but I wouldn't want to bet one of my
projects on that.

  - Dennis


On 04/06/2013 05:33 PM, Ted Yu wrote:
Thanks for the quick response, Dennis.

For ASM, it is not Apache license.
http://today.java.net/pub/a/today/2008/07/31/return-type-based-method-overloading.html#is-this-useful
And got the idea in my previous email.
Basically change of return type can be accommodated by introducing two interfaces. One for rev-1 method signatures, one for rev-2 method signatures. There is one to one correspondence between the methods in the two interfaces.
New implementation would implement both interfaces, using the technique shown above.
I know this is not beautiful but it should work.
Cheers
________________________________
Sent: Friday, April 5, 2013 9:19 PM
Subject: Re: [seajug] Compatibility between methods returning different types
 
Hi Ted,
AFAIK that should work without a problem.
The difficulty with the method return type change is

that the method signatures (including return type)
are actually included in the referencing class - so
if the return type has changed the method will no
longer be found and the classloader will report an
error. Change a class's inheritance won't break
anything in and of itself (as long as the same
methods are available) because that inheritance
structure is not in the binary class files.

If you want to try modifying class files your best

bet is probably to use ASM: http://asm.ow2.org/

  - Dennis
Here is another question.

public class A {
  public void a(int i) {
  }
}
Client compiles against above code.
public interface B {
  public void a(int i);
}
public class A implements B {
  public void a(int i) {
  }
}
Now without re-compilation, would the client jar generated earlier still run on top of new jar with the new class A ?
Thanks
________________________________
Sent: Friday, April 5, 2013 6:46 PM
Subject: Re: [seajug] Compatibility between methods returning different types
 
http://jasmin.sourceforge.net/
I also found http://www.eg.bucknell.edu/~cs360/java-assembler/
I wonder if anyone knows of other, more recent assembler(s).
Thanks
________________________________
Sent: Friday, April 5, 2013 8:09 AM
Subject: Re: [seajug] Compatibility between methods returning different types
 
Thanks for the pointer.
In hindsight, new method name should have been used.
The change was done by a friend who no longer actively works on the (open-source) project.
________________________________
Sent: Friday, April 5, 2013 7:34 AM
Subject: Re: [seajug] Compatibility between methods returning different types
 
You are trying to break the overloading rule.
There is no way to have two methods with the same name and same arguments by changing only  the return type. The compiler will complain.
However, if this back compatibility is such a strong requirement, you can always manipulate bytecodes, as described in 
http://today.java.net/pub/a/today/2008/07/31/return-type-based-method-overloading.html
I did not try that and I will never do.
I would rather change the name of the method or just add another argument.
Never forget that the person maintaining your code is a violent psychopath who knows where you live.
 

Hi,
  public void setValue(byte[] key, byte[] value) {
  public HColumnDescriptor setValue(byte[] key, byte[] value) {
The background is that in recent release, method signature was changed from first form to second form. I am trying to maintain binary compatibility for the clients which were compiled against first form.
The above code doesn't compile. If the parameter type were int, I can introduce a new method with same name and Integer type parameter.
Maybe expert on this forum can give me some advice.
Thanks

[Paul Z. Wu]

 For a reason I won't explain here, I need to link some files using "mklink" on windows in a project with Maven.  If I use soft links, maven cannot read the content of the files so it won't work.  I tried to use "more" to see the file, I cannot see the content either.  It seems windows soft link's implementation is strange...

 Now I have to use hard links, which is not exactly I wanted.
 
Paul Z. Wu
 
http://www.elookinto.com