The Java Language Features that Nobody Uses
I read Anthony Goubard’s “Top 10 Unused Java Features” on JavaLobby earlier today. I agree with some of his selections but I think he missed out a few key features that nobody uses. Restricting myself to just language features (the API is too huge), here are four more widely unused features of Java.
4. The short data type
You use it? I don’t believe you. Everybody* uses int when they want integers, even if they don’t need a 32-bit range.
3. Octal Literals
Who uses Octal these days?** Hexadecimal is a more useful shorthand for binary values. Worse, the leading-zero notation for Octal literals is just confusing:
int a = 60;
int b = 060;
System.out.println(a + b); // Prints 108.
2. Local Classes
Java has four types of nested class, three of which are widely used. As well as static nested classes, named inner classes and anonymous inner classes, you can also define named classes within methods, though it’s rare to see one in the wild.
public class TopLevelClass
{
public void someMethod()
{
class LocalClass
{
// Some fields and methods here.
}
LocalClass forLocalPeople = new LocalClass();
}
}
1. Strict FP
There is probably a programmer out there somewhere for whom Java’s strictfp is vital, but I haven’t met him or her. If you already know what strictfp is used for then you are probably in the top 5% of Java programmers. If you don’t know what strictfp does, here you go, welcome to the top 5%. It’s basically about making sure that your calculations are equally wrong on all platforms.
* OK, maybe you used to be a C programmer.
** Here’s your rhetorical answer.
(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)





Comments
Álvaro Martínez replied on Mon, 2009/04/20 - 3:06am
Fabrizio Giudici replied on Mon, 2009/04/20 - 4:21am
Fabrizio Giudici replied on Mon, 2009/04/20 - 4:23am
Siew Joon Tai replied on Mon, 2009/04/20 - 5:39am
Jason Hatton replied on Mon, 2009/04/20 - 7:50am
Vladimir Putin replied on Mon, 2009/04/20 - 11:25am
Nils Kilden-pedersen replied on Mon, 2009/04/20 - 2:54pm
in response to:
Jason Hatton
Mark Unknown replied on Mon, 2009/04/20 - 10:23pm
Jason Hatton replied on Tue, 2009/04/21 - 8:22am
in response to:
Nils Kilden-pedersen
Brian Sayatovic replied on Tue, 2009/04/21 - 9:14am
I actually used a local class once. It was in a screwy proprietary product from some vendor where you could "customize" by typing a snippet of Java that their product would inline into their method and recompile behind the scenes. As the logic we had to do was tedious, encapsulating bits of it in classes as very desirable. Because of local classes, I was able to create my own little OO microcosm inline with their method.
So... do I get smacked with the book?
Jason Hatton replied on Tue, 2009/04/21 - 9:34am
in response to:
Brian Sayatovic
Nils Kilden-pedersen replied on Tue, 2009/04/21 - 3:37pm
in response to:
Jason Hatton
If you need an inner class specific to only one method, there's no need to pollute the namespace of the entire class by defining it at the class scope. Here's a use case using GNU Trove collections:
int sum(TIntArrayList list) {class Total implements TIntProcedure {
int sum;
boolean execute(int value) {
sum += value;
return true;
}
}
Total total = new Total();
list.forEach(total);
return total.sum;
}
Jason Hatton replied on Tue, 2009/04/21 - 9:38pm
in response to:
Nils Kilden-pedersen
The example as is took me a few moments to understand. This immediately emits the complex code smell for me. Outside of this being a simple example if this was in the wild I would refactor the class to a full fledged class in the package space. Once this happens you can see that the class would actually be highly reusable. I hear the desire to not pollute the namespace but, I see a pollution of a method to achieve that. I even wonder if the single responsiblity principle is being stretched here but, I am not yet sure myself if that is true.
If the example were a more complex one, which would be hard to come up with if one weren't already available. I think the complexity would still be an issue.
I actually could see how Brian Sayatovic's example would be a proper use case although it was definitely on the edge.
Nils Kilden-pedersen replied on Wed, 2009/04/22 - 12:28pm
in response to:
Jason Hatton
Jason Hatton replied on Wed, 2009/04/22 - 2:39pm
in response to:
Nils Kilden-pedersen