Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.java.programmer > #33789 > unrolled thread

To deprecate or not

Back to article view | Back to comp.lang.java.programmer

Contents

  To deprecate or  not mike <mikaelpetterson@hotmail.com> - 2016-02-12 01:16 -0800
    Re: To deprecate or  not Eric Douglas <e.d.programmer@gmail.com> - 2016-02-12 05:59 -0800
      Re: To deprecate or not Arne Vajhøj <arne@vajhoej.dk> - 2016-02-13 11:02 -0500
        Re: To deprecate or not Eric Douglas <e.d.programmer@gmail.com> - 2016-02-15 05:12 -0800
          Re: To deprecate or not Arne Vajhøj <arne@vajhoej.dk> - 2016-02-15 11:42 -0500
    Re: To deprecate or not Arne Vajhøj <arne@vajhoej.dk> - 2016-02-13 11:34 -0500
    Re: To deprecate or  not Andreas Leitgeb <avl@logic.at> - 2016-02-15 00:53 +0000

#33789 — To deprecate or not

Hi,

I have an interface call it InterfaceTop that looks like this:

public InterfaceTop {  
  public String getValue(String arg1);

}

Then we have two sub interfaces call them InterfaceSub1 and InterfaceSub2.

They both extend IntefaceTop.

Now we discovered that the method in Inteface top produces erroneous output in
in implementation of InterfaceSub1. We need an additional parameter to get value:

public String getValue(String arg1, String arg2);

As I see it we have two alternatives:

1.Add 'public String getValue(String arg1, String arg2);' in InterfaceTop and @deprecate public String getValue(String arg1);

A consequence of this will be that I need to replace methods in implemetation. using InterfaceSub2. And handle a null or empty String for arg2. But we still have a common interface.

2. Add 'public String getValue(String arg1, String arg2);' to InterfaceSub1.
I still need to implement both methods in implementation. Maybe let the "faulty" method throw UnsupportedOperationException.

What is your view on this?

br,

//mike

[toc] | [next] | [standalone]

#33790

On Friday, February 12, 2016 at 4:17:01 AM UTC-5, mike wrote:
> Hi,
> 
> I have an interface call it InterfaceTop that looks like this:
> 
> public InterfaceTop {  
>   public String getValue(String arg1);
> 
> }
> 
> Then we have two sub interfaces call them InterfaceSub1 and InterfaceSub2.
> 
> They both extend IntefaceTop.
> 
> Now we discovered that the method in Inteface top produces erroneous output in
> in implementation of InterfaceSub1. We need an additional parameter to get value:
> 
> public String getValue(String arg1, String arg2);
> 
> As I see it we have two alternatives:
> 
> 1.Add 'public String getValue(String arg1, String arg2);' in InterfaceTop and @deprecate public String getValue(String arg1);
> 
> A consequence of this will be that I need to replace methods in implemetation. using InterfaceSub2. And handle a null or empty String for arg2. But we still have a common interface.
> 
> 2. Add 'public String getValue(String arg1, String arg2);' to InterfaceSub1.
> I still need to implement both methods in implementation. Maybe let the "faulty" method throw UnsupportedOperationException.
> 
> What is your view on this?
> 
> br,
> 
> //mike

That sounds like your easiest solution, if the second parameter is required and only for InterfaceSub1.

public interface InterfaceSub1 extends InterfaceTop {
public String getValue(String arg1) {
throw new UnsupportedOperationException("second parameter required for this method on this interface");
}
public String getValue(String arg1,String arg2) {
// new working code
}
}

[toc] | [prev] | [next] | [standalone]

#33794 — Re: To deprecate or not

On 2/12/2016 8:59 AM, Eric Douglas wrote:
> On Friday, February 12, 2016 at 4:17:01 AM UTC-5, mike wrote:
>> I have an interface call it InterfaceTop that looks like this:
>>
>> public InterfaceTop {
>>    public String getValue(String arg1);
>>
>> }
>>
>> Then we have two sub interfaces call them InterfaceSub1 and InterfaceSub2.
>>
>> They both extend IntefaceTop.
>>
>> Now we discovered that the method in Inteface top produces erroneous output in
>> in implementation of InterfaceSub1. We need an additional parameter to get value:
>>
>> public String getValue(String arg1, String arg2);
>>
>> As I see it we have two alternatives:
>>
>> 1.Add 'public String getValue(String arg1, String arg2);' in
>> InterfaceTop and @deprecate public String getValue(String arg1);
>>
>> A consequence of this will be that I need to replace methods in
>> implemetation. using InterfaceSub2. And handle a null or empty String
>> for arg2. But we still have a common interface.
>>
>> 2. Add 'public String getValue(String arg1, String arg2);' to InterfaceSub1.
>> I still need to implement both methods in implementation. Maybe
>> let
>> the "faulty" method throw UnsupportedOperationException.
>>
>> What is your view on this?
>
> That sounds like your easiest solution, if the second parameter is
> required and only for InterfaceSub1.
>
> public interface InterfaceSub1 extends InterfaceTop {
> public String getValue(String arg1) {
> throw new UnsupportedOperationException("second parameter required for this method on this interface");
> }
> public String getValue(String arg1,String arg2) {
> // new working code
> }
> }

The implementation code would need to be in the class implementing the
interface not the interface itself (unless Java 8 and marked as
default).

Arne

[toc] | [prev] | [next] | [standalone]

#33807 — Re: To deprecate or not

On Saturday, February 13, 2016 at 11:02:40 AM UTC-5, Arne Vajhøj wrote:
> The implementation code would need to be in the class implementing the
> interface not the interface itself (unless Java 8 and marked as
> default).
> 
> Arne

Correct.  I haven't come across a reason to deprecate an interface method like that, but that will work in Java 8+, which everyone ought to be using by now since Java 7 and older is unsupported and unsecure.  Surely there's some government agency running old Java because red tape won't let them update, but if their machines have internet access they're not secure, or there's some other firewall limiting what they can do.  I wouldn't expect government to be secure after the recent hacks against them.

Naturally deprecating the method in the interface with a runtime error is a hack to find calls to the now invalid method.  Is it the best way?  Unlikely, but what else can you do?  Are there other interfaces which extend the parent?  How many classes may be calling this now invalid method?

[toc] | [prev] | [next] | [standalone]

#33822 — Re: To deprecate or not

> ... but that will work in Java 8+, which everyone ought
> to be using by now since Java 7 and older is unsupported and
> unsecure.  Surely there's some government agency running old Java
> because red tape won't let them update, but if their machines have
> internet access they're not secure, or there's some other firewall
> limiting what they can do.  I wouldn't expect government to be secure
> after the recent hacks against them.

The free version of Oracle Java 7 is not supported any
longer.

Java 7u80 is the last free version released in April.

But it is a different situation for those paying for
support (including paying for application server support
when the application servers comes with a specific Java version).

According to Java 8 release notes there exist a Java 7u95
for Oracles paying customers.

And IBM also support their customers.

So a lot of those running Java 7 will actually have support.

Same for Java 6.

Arne

PS: And they should all have a lot of isolation level between
the internet and the application server.

[toc] | [prev] | [next] | [standalone]

#33795 — Re: To deprecate or not

On 2/12/2016 4:16 AM, mike wrote:
> I have an interface call it InterfaceTop that looks like this:
>
> public InterfaceTop {
>    public String getValue(String arg1);
>
> }
>
> Then we have two sub interfaces call them InterfaceSub1 and InterfaceSub2.
>
> They both extend IntefaceTop.
>
> Now we discovered that the method in Inteface top produces erroneous output in
> in implementation of InterfaceSub1. We need an additional parameter to get value:
>
> public String getValue(String arg1, String arg2);
>
> As I see it we have two alternatives:
>
> 1.Add 'public String getValue(String arg1, String arg2);' in InterfaceTop and
 > @deprecate public String getValue(String arg1);
>
> A consequence of this will be that I need to replace methods in implemetation. using
 > InterfaceSub2. And handle a null or empty String for arg2. But we 
still have a
 > common interface.
>
> 2. Add 'public String getValue(String arg1, String arg2);' to InterfaceSub1.
> I still need to implement both methods in implementation. Maybe let the "faulty" method
 > throw UnsupportedOperationException.
>
> What is your view on this?

Your option #1 is:

package february;

public class OptionOne {
	public static interface InterfaceTop {
		@Deprecated
		public String getValue(String arg1);
		public String getValue(String arg1, String arg2);
	}
	public static interface InterfaceSub1 extends InterfaceTop {
	}
	public static interface InterfaceSub2 extends InterfaceTop {
	}
	public static class ClassImpl1 implements InterfaceSub1 {
		@Override
		public String getValue(String arg1) {
			throw new UnsupportedOperationException("Missing argument");
		}

		@Override
		public String getValue(String arg1, String arg2) {
			return arg1 + arg2;
		}
	}
	public static class ClassImpl2 implements InterfaceSub2 {
		@Override
		public String getValue(String arg1) {
			return arg1;
		}
		@Override
		public String getValue(String arg1, String arg2) {
			return getValue(arg1); // I think this is convenient
		}
	}
	public static void main(String[] args) {
		InterfaceTop i1 = new ClassImpl1();
		System.out.println(i1.getValue("ABC", "DEF"));
		InterfaceTop i2 = new ClassImpl2();
		System.out.println(i2.getValue("ABC", null));
	}
}

Your option #2 is:

package february;

public class OptionTwo {
	public static interface InterfaceTop {
		public String getValue(String arg1);
	}
	public static interface InterfaceSub1 extends InterfaceTop {
		@Deprecated // I think this should be added
		public String getValue(String arg1);
		public String getValue(String arg1, String arg2);
	}
	public static interface InterfaceSub2 extends InterfaceTop {
	}
	public static class ClassImpl1 implements InterfaceSub1 {
		@Override
		public String getValue(String arg1) {
			throw new UnsupportedOperationException("Missing argument");
		}

		@Override
		public String getValue(String arg1, String arg2) {
			return arg1 + arg2;
		}
	}
	public static class ClassImpl2 implements InterfaceSub2 {
		@Override
		public String getValue(String arg1) {
			return arg1;
		}
	}
	public static void main(String[] args) {
		InterfaceSub1 i1 = new ClassImpl1();
		System.out.println(i1.getValue("ABC", "DEF"));
		InterfaceSub2 i2 = new ClassImpl2();
		System.out.println(i2.getValue("ABC"));
	}
}

I have an option #3 that uses a Java 8 feature to improve option #1:

package february;

public class OptionThree {
	public static interface InterfaceTop {
		public String getValue(String arg1);
		public default String getValue(String arg1, String arg2) {
			return getValue(arg1);
		}
	}
	public static interface InterfaceSub1 extends InterfaceTop {
	}
	public static interface InterfaceSub2 extends InterfaceTop {
	}
	public static class ClassImpl1 implements InterfaceSub1 {
		@Override
		public String getValue(String arg1) {
			throw new UnsupportedOperationException("Missing argument");
		}

		@Override
		public String getValue(String arg1, String arg2) {
			return arg1 + arg2;
		}
	}
	public static class ClassImpl2 implements InterfaceSub2 {
		@Override
		public String getValue(String arg1) {
			return arg1;
		}
	}
	public static void main(String[] args) {
		InterfaceTop i1 = new ClassImpl1();
		System.out.println(i1.getValue("ABC", "DEF"));
		InterfaceTop i2 = new ClassImpl2();
		System.out.println(i2.getValue("ABC"));
	}
}

I also have an option #4:

package february;

public class OptionFour {
	public static interface InterfaceTop {
		public String getValue(String... args); // note that it can be array 
or Map or custom interface/class
	}
	public static interface InterfaceSub1 extends InterfaceTop {
	}
	public static interface InterfaceSub2 extends InterfaceTop {
	}
	public static class ClassImpl1 implements InterfaceSub1 {
		@Override
		public String getValue(String... args) {
			if(args.length == 2) {
				return args[0] + args[1];
			} else {
				throw new UnsupportedOperationException("Invalid number of arguments");
			}
		}
	}
	public static class ClassImpl2 implements InterfaceSub2 {
		@Override
		public String getValue(String... args) {
			if(args.length == 1) {
				return args[0];
			} else {
				throw new UnsupportedOperationException("Invalid number of arguments");
			}
		}
	}
	public static void main(String[] args) {
		InterfaceTop i1 = new ClassImpl1();
		System.out.println(i1.getValue("ABC", "DEF"));
		InterfaceTop i2 = new ClassImpl2();
		System.out.println(i2.getValue("ABC", null));
	}
}

My preferences are:

if time to rework things properly then
     go for option #4
else
    if Java 8 then
       go for option #3
    else
       go for option #2
    end if
end if

I would never go for option #1.

Arne

[toc] | [prev] | [next] | [standalone]

#33797

mike <mikaelpetterson@hotmail.com> wrote:
> I have an interface call it InterfaceTop that looks like this:
> public InterfaceTop {  
>   public String getValue(String arg1);
>
> }
> Then we have two sub interfaces call them InterfaceSub1 and InterfaceSub2.
> They both extend IntefaceTop.
> Now we discovered that the method in Inteface top produces erroneous output in
> in implementation of InterfaceSub1. We need an additional parameter to get value:
> public String getValue(String arg1, String arg2);

If ISub1 implementations need the 2-args method, and ISub2 implementations
don't need it, then the question is, whether ITop should even remain a
parent interface of ISub1 - or if the method should even remain in ITop 
at all.

Interfaces are used to deal with a variety of implementations by a common 
API.  But if the variety of implementations doesn't agree on that common
API, then you should consider redesigning the interface hierarchy.
(and bumping the major version number, if it is in a non-private library.)

> Maybe let the "faulty" method throw UnsupportedOperationException.

Imho, that is a very bad idea. It's a way to defer errors to runtime that 
could otherwise (with refined interfaces) be detectable at compile time.

PS: I know that the JSL uses a similar pattern for unmodifiable* classes,
  but that's not quite the same, imho.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.java.programmer

csiph-web