Want create site? Find Free WordPress Themes and plugins.

Its ironic the stuff we get used to as developers. Theres so much we do repeatedly in every class or in every project or maybe even in every method yet we never realize that its probably best to add a new feature to java to make our life easier. While searching for some reading material on javas 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, lets see what people have come up with. And thats just week 4 submissions. Some of my personal favorites are:

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();

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

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.

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.

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 its 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.

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.

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.

Did you find apk for android? You can find new Free Android Games and apps.
Share.

Leave A Reply