Prohibit the use of methods from superclasses


Posted by Steven

A couple of days ago, I saw an interesting way to prohibit the use of a method from a superclass. A coworker of mine wrote a subclass of a JTextField that should display a date in a specific fashion. Before you comment the obvious: Yes, there where reasons not to use JFormattedTextField. ;)

Here's how he wrote the new class:

  1. public class CustomDateField extends JTextField {
  2.  
  3. 	public void setDate(Date date) {
  5. 		c.setTime(date);
  6.                 // the real method was a bit more complicated, but for the example that is sufficient
  7. 		super.setText(String.valueOf(c.get(Calendar.YEAR)));
  8. 	}
  9.  
  10. 	/**
  11. 	 * @deprecated Use setDate(Date date) instead
  12. 	 */
  13. 	@Deprecated
  14. 	@Override
  15. 	public void setText(String arg0) {
  16. 		throw new RuntimeException(
  17. 				"This method is not supported. Use setDate(Date date) instead.");
  18. 	}
  19. }

Because the new textfield should only work with java.util.Date, the common setText() is rendered unusable. Therefore, a new method is offered. The class works as follows:

  1. public class CustomDateFieldTest {
  2.  
  3. 	CustomDateField field;
  4.  
  5. 	@Before
  6. 	public void before() {
  7. 		field = new CustomDateField();
  8. 	}
  9.  
  10. 	@Test(expected = RuntimeException.class)
  11. 	public void setTextDoesntWorkAnymore() {
  12. 		field.setText("Text");
  13. 	}
  14.  
  15. 	@Test
  16. 	public void setDateWorks() {
  17. 		Date date = new Date();
  18. 		field.setDate(date);
  19. 		assertEquals("field.getText()", "2013", field.getText());
  20. 	}
  21. }

Because I've never seen this combination of @Deprecated and throwing an exception before, I want to record it here.

Comments

This breaks existing code in a real mean way: It still compiles, but it doesn't work. If you are willing to break existing code in such a harsh fashion just remove the method completely.

Posted by Jens Schauder (not verified) on Jan 13th, 2013 at 12:40 pm.

How exactly does this break existing code? Because this class is new, there are no uses of it, hence no code gets broken. The only way I can think of is referencing the super class of the new class (JTextField) in a collection. This way, there is a collection of JTextField from which some will throw exceptions when setting a text - namely the new subclasses. That sounds bad ... did you mean that?

Posted by Steven on Jan 13th, 2013 at 2:30 pm.