There are times when you need to format a integer or double value into a String, with the comma for values larger than a thousand. If you need to format a numeric value correctly based on the local formatting rules for numbers use the NumberFormat class. Different locales have different formatting rules, for example in France they use the comma as a decimal point where in the United States the comma is used for delimiting large numbers.
double val = 123456.78;
System.out.println(val); // 123456.78
// Use default locale to format string
String localFormat = NumberFormat.getNumberInstance().format(val);
System.out.println(localFormat); // 123,456.78
String frenchFormat = NumberFormat.getNumberInstance(Locale.FRANCE).format(val);
System.out.println(frenchFormat); // 123 456,78
For the longest time I’ve used java.rmi.server.UID to create a unique ID in a application. We enhanced the UID class to fit our needs and to format the ID to the standard format but unfortunately we found that within a process, we were generating duplicate IDs if we created more than a certain amount. It didn’t take much to remedy the problem since Java introduced java.util.UUID in Java 1.5.
To create a universally unique ID in Java 1.5 or greater just call the static randomUUID method on the UUID class.
UUID has a wider range of possible values that I’m not concern of duplicate values or collisions for my application.
We all have heard of missiles blowing up in midair because of the wrong unit was used in calculating the trajectory or bank software that misplaced millions of dollars because of a decimal place. It might not compare against blowing up a multi-million dollar missile but here are some of the worst software bugs I’ve seen in projects where I’ve worked.
Shift + O Short Cut – I once worked on a software application where one of the engineers developed a screen search functionality that would find the UI screen by name or feature. Needless to say the modal pop-up dialog for this search feature popped up when the user hit the Shift + O keys. This feature was developed by the engineer on his own initiative, so you can imagine everyone’s surprised when we couldn’t even type a capital o without this thing popping up.
Exposing Regular Expressions – In another project we developed micro expression language which was used and exposed at the application level to users. In one situation, a user reported a error when he wanted to replace a variable place holder with a dollar amount. It seems that when he called the expression language replaceall(“AMOUNT_VALUE”, “$0.00″) the got back the value of AMOUNT_VALUE.00. This problem was caused because we used Java Regular Expressions feature of the String class and $0 expression is a special value in the Java RegEx. This was like a Regular Expression Injection bug.
Localization and Internationalization – In the same project we had a problem with displaying the correct currency symbol used in a financial account statement. There is a big difference between $100 and €100. Account holders are not happy to know that their €100 are now worth $100.
Cut/Copy/Paste Does Not Work – I have seen way too many Java/Swing application where some component does not have proper support for cut, copy, or paste. When you cut from a Java application and paste to say Notepad you get a stringified Java object.
Textarea Size Limit – When filling online forms, the one bug that just kills me is where a textarea has a size limit not shown and you spend time typing a long response which will be either truncated, lost, or rejected on submit.
You’ll always have to deal with memory issues, no matter the programming language. Even with the Java programming language, if the right precautions are not taken, you will have some sort of memory leaks, memory issue, out of memory exception, or heap size problem. I’ve seen two common types of memory issues in every application I’ve worked on.
A common source of memory leaks is global static singleton god object that collects or manages a lot of data, maybe a system cache, object lookup table, service locator, etc. This type of singleton pattern will require other objects to register with it, add themselves to the global pool of objects, but if they are not properly removed, unregistered, when they are no longer needed you will see your memory usage increase over time. I’ve seen this issue when using the callback or listener pattern and the listener object itself holds a lot of other data. This sort of problem is usually relatively easy to identify with a profiler, it will usually be one of the largest objects in your system.
The other, more difficult memory leak to identify, is when you have hundreds of thousands of objects each taking up a reasonable amount of memory. In this case, a single object instance will not take a lot of memory but collectedly the hundreds of thousands of objects can eat up a lot of memory. Here are a few things you can think about when dealing with a small class that spawns thousand of objects…
If you have int types, see if you can change them to short or byte types. Try subclassing if you have any number of properties that most often than not set or are null. Think about lazy loading arrays, lists, and other objects references. If there are many object instances of this class, and any portion of these instances are logically equivalent, think of using the flyweight pattern.
There are times when you don’t have full control of the location where your Java application runs from. This could happen because the application is installed in a location other than the one recommended by the installer, or because it ran from the IDE, or some other reason. For whatever reason, if you need to find the current working directory where your Java application runs there are two different approaches. The first approach is to use the File class and the current directory symbol to find the current directory. Remember that the single period “.” represents the current directory and two periods “..” represents the parent directory.
String currentPath = new File(".").getCanonicalPath();
Unfortunately, using the File class throws an IOException. There is another approach that does not throw an exception and returns the same absolute path to the current directory where the Java application is running from.
String currentPath = System.getProperty("user.dir");