stevenschwenke.de

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:

public class CustomDateField extends JTextField {
 
	public void setDate(Date date) {
		Calendar c = new GregorianCalendar();
		c.setTime(date);
                // the real method was a bit more complicated, but for the example that is sufficient
		super.setText(String.valueOf(c.get(Calendar.YEAR)));
	}
 
	/**
	 * @deprecated Use setDate(Date date) instead
	 */
	@Deprecated
	@Override
	public void setText(String arg0) {
		throw new RuntimeException(
				"This method is not supported. Use setDate(Date date) instead.");
	}
}

With the last post of this series, I started experimenting with JavaFX. Since then, I figured out how to separate the user interface (UI) framework from the business logic and how the life cycle of the objects should be like.

First impressions

As I explained before, I want to write a small simulation in which some civilization uses growing resources to expand. The whole idea is pretty scetchy right now, but there should be a bord on which the whole simulation takes place and the mentioned resources. Because resources don't grow on their own, there are resource spawners that can be set programmatically and appear on the UI. These things spawn new resources every time the user clicks on them. The new resources (yellow thingies) are spread in a random fashion around the spawners (grey buttons):