Java tips for coders, by coders

It’s ironic the stuff we get used to as developers. There’s so much we do repeatedly in every class or in every project or maybe even in every method yet we never realize that it’s probably best to add a new “feature” to java to make our life easier. While searching for some reading material on java’s handling of String (just to clear up some of my own personal doubts) I came across a very interesting OpenJDK sub-project, Coin. Coin, simply put, is a project to determine what small language changes should be added to JDK7. Wonderful, let’s see what people have come up with. And that’s just week 4 submissions.

Some of my personal favorites.
1. Simplified StringBuffer/StringBuilder syntax – God yes, please. The proposal simply says that instead of only allowing String literals to be added with the + operator, other String “types” such as StringBuilder and StringBuffer should be allowed too.
Before:

public String toString() {
		String s = null;
		StringBuilder sb = new StringBuilder();
		sb.append("Printing properties -- ");
		for (Object object : someCollection) {
			sb.append(object.toString());
		}
		return sb.toString();
	}

After:

	public String toString() {
		String s = null;
		StringBuilder sb = "Printing properties -- ";
		for (Object object : someCollection) {
			sb += object.toString();
		}
		return sb.toString();
	}

That’s a small example but the code can get dirty pretty fast with bigger sets of data. You can’t imagine how many times I have had to decide between faster code and dirty code. It’s probably my most wanted feature.

2. Simple Operator Overloading – The proposal wants to slightly change the JLS to accept the following set of operators to be applied differently based on the implementation.
"[]", "[]=", "+", "-", "~", "!", "*", "/", "%", "+=", "-=", "*=", "/=", %=

Basically, you should be able to do the following in less lines of code.
Before:

p.setWeight(p.getWeight() + 20);

After:

p = p + 20;

This again improves code readability but it does place the extra work on the developer because one needs to go in and check what exactly the + operator does for that particular class. I’m sure most of us are willing to make that trade-off for cleaner, easier to read code.

3. Concise Collection Initialization Syntax – Another must-have addition. Collection initialization syntax is quite ugly right now. To create an immutable list of integers right now:

public List<Integer> getList() {
		List<Integer> list = new ArrayList<Integer>();
		list.add(1);
		list.add(23);
		list.add(5);
		return Collections.unmodifiableList(list);
	}

The complexity of maintaning such code increases over time because items may need to be added and removed depending on requirements. The proposed change suggest something like:

public List<Integer> getList() {
		final List<Integer> list = new ArrayList<Integer>()[1, 23, 5];
		return Collections.unmodifiableList(list);
	}

Very clean and easily readable. The list is not such a good example but if you read the proposal you’ll see what wonders is does to other collection types such as Sets and Maps.

4. Abstract Enums – Not often does one come across a requirement which justifies this particular change but when you do, you’ll give an arm and a leg to have this feature. I have come across such a change only once ever but the solution implemented without this particular feature was as ugly as described in the proposal documents. This is the kind of change that gives you satisfaction that it’s there but you don’t NEED it either because you aren’t going to be using it that much. Either way, there is nothing wrong with evolving the java enums in the proposed way.

5. Allow the class literal of the surrounding class to be referenced with the ‘class’ keyword – Another very useful addition. While it doesn’t add much by way of functionality but it sure makes creating loggers etc a breeze. Not only that, it just removes code maintenance associated with refactoring of code.

6. Sameness operators – I couldn’t agree more with what has been said in the proposal. The part about overloading < and > for objects is something that should have already been there in java. It just seems like the easiest thing to do.
Before:

if (a.compareTo(b) < 0) {
    // do something
}

After:

if (a < b) {
    // do something
}

There’s other operators also mentioned which should ALL help in cleaning up code.

That’s all the proposals that I could go through but if you’re interested in them all you can read them here, here, here, here and here.

No related posts.