Dan is the founder of Rectangular Software, an independent UK software company that provides development services and builds its own mobile and web applications. Dan has over a decade of experience in the software industry, building a wide variety of systems including casino, poker and spread-betting platforms, mobile applications, e-commerce websites, and network security software. His other programming interests include artificial intelligence, particularly evolutionary computation, and functional programming in Haskell. He has authored, or contributed to, a number of open source Java projects. Dan has posted 34 posts at DZone. You can read more from them at their website. View Full User Profile

The Java Language Features that Nobody Uses

04.20.2009
| 11058 views |
  • submit to reddit

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.

From http://blog.uncommons.org

Published at DZone with permission of its author, Dan Dyer.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Tags:

Comments

Álvaro Martínez replied on Mon, 2009/04/20 - 3:06am

I use "short" constantly xD

Fabrizio Giudici replied on Mon, 2009/04/20 - 4:21am

I do use short :-P but I admit, I use it for image processing.

Fabrizio Giudici replied on Mon, 2009/04/20 - 4:23am

I do use short :-P but I admit, I use it for image processing.

Siew Joon Tai replied on Mon, 2009/04/20 - 5:39am

Good one! I didn't know about the Local Class part.

Jason Hatton replied on Mon, 2009/04/20 - 7:50am

A local class.  Your kidding.  This is some sort of parody right?!?!? Aren't inner classes and anonymous classes wretched enough?  If I saw one of those in the wild I would smack the person over the head with a telephone book and the Thinking in Java book for good measure.

Vladimir Putin replied on Mon, 2009/04/20 - 11:25am

I use generated short fields of JPA entities

Nils Kilden-pedersen replied on Mon, 2009/04/20 - 2:54pm in response to: Jason Hatton

Don't be a douche. If you don't know what they are good for then don't use them. But don't flaunt your ignorance in a public forum.

Mark Unknown replied on Mon, 2009/04/20 - 10:23pm

I am not from GB, but i got the League of Gentlemen ref. Anyone else?

Jason Hatton replied on Tue, 2009/04/21 - 8:22am in response to: Nils Kilden-pedersen

Tell me what you think they are good for.  If you are looking for encapsulation at that small of a scope.  I see very little value. Just ugly, overly complicated, hard to read, hard to test code . If you have behavior that deserve a class make it a class. Otherwise use the Single Responsibility Principle and break it up over smaller methods. You will have more readable and testable code. Oh and I can see where Local Classes could be an argument for Single Responsiblity but the previous reason of ugly, hard to read, and hard to test for me override the use. If you want to talk intellictually - talk intellectually.

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

There are always exceptions.  In your case you had to deal with a design issue that was influenced by a third party.  So yes it sounds ugly but, you had the restrictions to deal with so I reserve the book. :)  I was trying to be tongue and cheek when I made that statement.  Evidently it rub some raw nerves

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

The example was simplified. If the class is reuseable, then yes, put it in a package. The cases I deal with are similar to anonymous inner classes, i.e. not reuseable and specific to the method it's in, yet there's a need to retain certain information about its work. Method local classes are perfect for that.

Jason Hatton replied on Wed, 2009/04/22 - 2:39pm in response to: Nils Kilden-pedersen

I appreciate the discussion Nils.  It seems like a very edge feature I might consider them in a case where the encapsulation needs far outweigh the complexity they incur.  If they are used just be more OO or to provide an elegant geeky solution that in my experience leads to more trouble than it is worth.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.