Results tagged “Java Tips”

At work I regularly stumble across a specific type of processing: sorting a collection/list and afterwards only retrieving the first or last element. Such code constructs are clearly for fetching the minimum or maximum element but sorting the whole collection for just a single item seems to be a bit of overhead. And indeed it is and the Collection class provides methods for these purposes without having to juggle items in memory and creating new collection objects which are never really required.


Advice

If you have a collection and want to retrieve the minimum or maximum element from it you don't have to sort it and retrieve the first or last but java.util.Collections offers its min() and max() methods for that which are much more efficient for that exact purpose. These can also be used with custom Comparators.

Code-Example

Before

// retrieve smallest element
Collections.sort(elementList);
Element smallest = elementList.get(0);    
...
// fetch item with highest custom value
Collections.sort(customItemsList, Collections.reverseOrder(new MyCustomComparator()));
Item largestItem = customItemsList.get(0);

After

Element smallest = Collections.min(elementList);    
...    
Item largestItem = Collections.max(customItemsList, new MyCustomComparator());

Benefit

Readability gain. Possible huge performance gain, as min()/max() run in O(n) while sorting takes O(n log(n)).

Remarks

If the comparison methods (compare(), equals()) do not fulfill the Comparator requirements according to the Java SDK (see here) (i.e. A.equals(B) != B.equals(A) or (A<B)!=(B>A), etc.) then the result of min()/max() may be different than the result from the approach using sorted collections.

|

Another quick addition to my Java Tips series. This instance deals again with adding some safety while reducing a bit of code clutter.


Advice

Use Commons ObjectUtils.toString() instead of directly calling toString() on an object if it may be null. This also allows for a alternate result if the object is null.

Code-Example

Before

final String projectId = (request.getParameter("projectid") != null) ? request.getParameter("projectid").toString() : "";
final String roleId = (request.getParameter("roleid") != null) ? request.getParameter("roleid")
        .toString() : "DEFAULT";

After

final String projectId = ObjectUtils.toString(request.getParameter("projectid"));
final String roleId = ObjectUtils.toString(request.getParameter("roleid"), "DEFAULT");

Benefit

Readability gain. Safety gain, as ObjectUtils methods are null-safe. The reduced code footprint eases recognition of the intention, which is even more significant if there should be a default text if the object instance is indeed null.

Remarks

None.

|

Another quick-shot Java Tip. Keeping it simple because I don't have much time currently. It's one of the lesser-known facts of the instanceof-operator and I've seen it's applicability in some sources but YMMV.


Advice

Use the Java operator instanceof for implicit null-checks. Sometimes there is the need to check for both (eg. in equals()-methods), non-null and a certain class. Instead of checking for each condition seperately one can use just the instanceof operator, which handles a null-pointer in the same manner as a non-matching class.

Code-Example

Before

...
if (field != null) {
    if (field instanceof SomeClass) {
        ...
    }
}
...

After

...
if (field instanceof SomeClass) {
    ...
}
...

Benefit

Small readability gain.

Remarks

This seems to be one of the lesser known facts about Java there can be a small confusion with other participants on the same code who interpret this to an aparently missing null-check. But this comes as no danger when the other person just re-adds the null-check, there should be no bad effect on the logic. Maybe just spread this knowledge to your participants somehow ;)

| | Comments (1)

After quite some time this is another instance of the Java Tips. It's an addition to the Apache Commons related framework tips which are guiding into the direction that as a developer you should take advantage of existing and proven frameworks and know their features to leverage your development efficiency. This time complexity of the given example is a bit higher than in the previous tips.


Advice

Use Apache CollectionUtils for evaluation and manipulation of Collections.

Code-Example

A short spoiler for the following code: This is a routine which checks a given set of categories against a set of category-permissions for a user. The result is a set of categories, which the user is allowed to access.

Before

...
public boolean hasPermissionsToAccessCategory(String category) {
    return (this.permissions != null && this.permissions.contains(category));
}
...

...
public Set<String> getCategoriesAllowedToViewBySearchFilter() {
    Set<String> result = null;
    if ((this.filter != null && this.filter.getCategory() != null) && (!this.filter.getCategory().isEmpty())) {
        result = new HashSet<String>();
        for (String category : this.filter.getCategory()) {
            if (this.hasPermissionsToAccessCategory(category)) {
                result.add(category.toString());
            }
        }
        if(result.size() == 0) {
            result = null;
        }
    } else {
        result = this.getAllCategories();
    }

    return result;
}
....

After

...         
public Set<String> getCategoriesAllowedToViewBySearchFilter() {
    Set<String> result = null;
    if (this.filter != null &&
        this.permissions != null &&
        CollectionUtils.isNotEmpty(this.filter.getCategory())) {

        // get only categories, which are both in permissions and filter categories
        result = new HashSet<String>(CollectionUtils.intersection(this.permissions, this.filter.getCategory()));

        // if no results, return null
        if(result.isEmpty()) {
            result = null;
        }
    } else {
        result = this.getAllCategories();
    }

    return result;
}
...

Benefit

Huge readability gain and a safety gain. The code and intention is much clearer here and also has a smaller footprint. The maintainability has been raised because for a developer not familiar with the routine it needs a bit of brainpower to find out what the initial code really does. The removal of the additional method and usage of CollectionUtils.intersection() makes it much easier to understand, how the two sets are compared to each other to retrieve the correct results.

Remarks

None if you are initially writing similar logic. If you're refactoring a method which seems to be better off with framework-provided functionality be careful and think over it a second time. Re-evaluate the code until you're really sure because it's easy to overlook a small detail which changes the results for a certain special case.

|

And we're continuing with our next Java Tip. Back on using frameworks for our convenience, I present another often useful possibility to let the StringUtils handle lots of work for you.


Advice

Use Apache StringUtils for concatenating Strings from Arrays or Lists, also when you need to delimit them with an arbitrary string.

Code-Example

Before

...
SQL_WHERE += " AND V.cat_display_name IN (";
boolean addComma = false;
for (String category : filter.getCategories()) {
  if (addComma) {
    SQL_WHERE += ", ";
  }
  SQL_WHERE += "'" + category + "'";
  addComma = true;
}
SQL_WHERE += ") ";
...

...
String SQL = "";
for(String category: filter.getCategories()) {
    SQL += val + ", ";
}
SQL = SQL.substring(0, SQL.length()-2);
....

After

...         
SQL_WHERE += " AND V.cat_display_name IN (";
SQL_WHERE += "'" + StringUtils.join(filter.getCategories(), "', '") + "'";
SQL_WHERE += ") ";
...

Benefit

Huge readability gain and a safety gain. The code and intention is much clearer and the possibility to hide bugs in the loop-logic (which I have seen often) is not present. Also, depending on the length of the Array or List, it may also present a small performance gain (see Java Tip #2) but that's in most such cases neglibigle.

Remarks

None.

|

On to the next Java Tip. Again, this time I'm staying within the boundaries of the Sun JDK.


Advice

When traversing a Map, always use the minimum necessary methods to get keys/values out.
<Map>.entrySet() vs. <Map>.keySet() vs. <Map>.values()

Code-Example

Before

...
 for (String number : phoneBook.keySet()) {
   PhoneBookEntry name = phoneBook.get(number);
   if (name != null) {
...

...
 for (String parameterKey : paramMap.keySet()) {
   Object value = paramMap.get(parameterKey);
...

After

...         
// if only values are needed
for(PhoneBookEntry name : phoneBook.values()) {
  if (name != null) {
...

...
// if key&value are needed
for(Entry<String, Object> entry : paramMap.entrySet()) {
  String parameterKey = entry.getKey();
  Object value = entry.getValue();
...

Benefit

Performance gain. Map is only searched once instead twice (and also the hashing for get() is avoided), or there is only the really required data extracted and returned from the map. Furthermore having only the required data around avoids later confusion on the original intent ("... is the key maybe used somewhere or just a leftover?...").

Remarks

None.

|

The Java Tips series gets another entry, yay! I'll keep within the plain Java language this time, no frameworks or other fancy tricks, just basic Java know-how.


Advice

Use Java5's for-each loop instead of manually iterating over arrays or collections whenever it is possible.

Code-Example

Before

...
// access using index
for (int i = 0; i < offerList.getMembers().size(); i++) {
    CustomizedOfferOverviewDTO dto = (CustomizedOfferOverviewDTO)offerList.getMembers().get(i);
...
}
...
// access using iterator
Iterator iter = m_elements.iterator();
while (iter.hasNext()) {
    ILoadable loadable = (ILoadable)iter.next();
...
}
...

After

...
for(CustomizedOfferOverviewDTO dto : offerList.getMembers()) {
...
}
...
for(ILoadable loadable : m_elements) {
...
}
...

Benefit

Readability gain. The for-each makes it a lot easier to iterate over collections and arrays and to read and recognize the code. Furthermore the Java compiler might also be able to optimize the loop a bit better internally but in general this improvement is beyond measuring accuracy and therefore is not an argument in this case.

Remarks

This only works as long as it's not modifying the collection or array beneath it. If deleting or replacing elements, you have to use the previous-style looping again where you have direct access to the Iterator.

|

Tip #5 in my Java Tips series is again focussing around the Apache Commons framework. In the same manner the StringUtils simplifies many common operations on Strings (see also Java Tip #3), DateUtils ease some of the pain when working with Java Date objects.


Advice

Use Commons DateUtils to manipulate and calculate dates.

Code-Example

Before

...
private static Date add(Date date, int field, int amount) {
    Calendar cal = Calendar.getInstance();
    cal.setTime(date);
    cal.add(field, amount);
    return cal.getTime();
}
...
public static Date getNextDay() {
    return add(getCurrentDay(), Calendar.DATE, 1);
}
...

After

...
public static Date getNextDay() {
    return DateUtils.addDays(getCurrentDay(), 1);
}
...

Benefit

Huge readability gain. By using DateUtils for calculating and manipulating Dates the code footprint gets smaller and easier to read. Furthermore by using explicit methods like addDays() it is clearer which part of a date is to be modified, compared to the partly ambiguous constants in the Calendar class. DateUtils also contains methods to round or truncate Dates to certain parts of the date, eg. truncate() by Calendar.HOUR sets minutes, seconds and miliseconds to zero.

Remarks

None.

|

Tip #4 of the Java Tips series is just a quick tip to enhance the codes robustness.


Advice

When comparing constants, always compare the constant to the unknown value.

Code-Example

Before

if(str != null && str.equals("XYZ")) { ... }
if(value != null && value.equals(SomeEnum.ENUM_1)) { ... }

After

if("XYZ".equals(str)) { ... }
if(SomeEnum.ENUM_1.equals(value)) { ... }

Benefit

Safety gain. Minor readability gain. The constant value can be compared to a null value without resulting in a NullPointerException. The check for null can be skipped because when the constant is compared to null the condition simply evaluates to a boolean false.

Remarks

None.

|

The next tip in my series of Java Tips deals with the usage of Java frameworks. Some people still have a certain hatred against Java frameworks because many of them have been not easy to deal with in in their past. Nevertheless, while those have either disappeared or evolved in a more usable shape, there have always been some frameworks which were rock-solid and widely accepted as simple and extremely useful. One of those is the Lang package in the library collection of the Apache Commons. In my opinion this one is a must-have for almost every Java project or application. Use it. Period.


Advice

Use Commons StringUtils for checking Strings content for null, emptiness or blankness.

Code-Example

Before

if(str != null && !str.equals("")) { ... }
if(str != null && !str.trim().equals("")) { ... }
if("".equals(str)) { ... }
if(str == null || "".equals(str.trim())) { ... }

After

if(StringUtils.isNotEmpty(str)) { ... }
if(StringUtils.isNotBlank(str)) { ... }
if(StringUtils.isEmpty(str)) { ... }
if(StringUtils.isBlank(str)) { ... }

Benefit

Huge readability gain. Safety gain, as StringUtils methods are null-safe. By using the provided utility methods from StringUtils the intent of a condition is much easier and faster to recognize. Furthermore, since all methods of StringUtils are able to correctly process null Strings, there is no danger of an unexpected NullPointerException anymore because of a forgotten null-check.

Remarks

None.

|

And on to the next in a series of Java Tips. While last time the performance gain was very tiny and only affected high-load scenarios, this tip may considerably speed up even simple applications where there is String-processing involved.


Advice

Use StringBuilder instead of + or += to concatenate Strings in non-linear cases (when concatenation not appears immediately one after another), ie. in loops.

Code-Example

Before

  String test = "";
  for(int i = 0; i < 50000; i++) {
     test += "abc";
  }

After

  StringBuilder test = new StringBuilder();
  for(int i = 0; i < 50000; i++) {
     test.append("abc");
  }

Benefit

Huge performance gain! The unoptimized code forces Java to create new Strings and copy the contents around all the time (because Strings are immutable in Java). The optimized code avoids this creation/copying by using StringBuilder. While the Java compiler can optimize linear concatenations, ie.

String test = "a" + "b" + "c";

into using a StringBuilder internally, it is not clever enough to apply this optimization correctly if there is more logic than just concatenation involved. Even if the concatenation is the only operation inside some loop-logic, the Java compiler falls back into creating a whole lot of String (or to be more exact: StringBuilder) objects, copying them around like crazy and causing a huge performance impact in some cases. I confirmed this example for measurement of StringBuilder performance: concatenating 50000 times "abc" in a loop takes ~11000ms, using StringBuilder keeps the time spent at near 0ms. (I tried concatenating with 500000 iterations, but stopped the execution of the first loop after ~10 minutes running unfinished, so the impact is nonlinear. Second loop finished in 15ms with 500000, for the record.)

Remarks

It is not necessary to optimize code like

String email = user + "@" + domain + ".com";

as javac is clever enough for these cases and it would reduce readability considerably. But even with the simplest loops involved the conditions change. For example, internally the first loop gets compiled by javac into following bytecode

 13  new java.lang.StringBuilder [24]
 16  dup
 17  aload_1 [test]
 18  invokestatic java.lang.String.valueOf(java.lang.Object) : java.lang.String [26]
 21  invokespecial java.lang.StringBuilder(java.lang.String) [32]
 24  ldc <String "abc"> [35]
 26  invokevirtual java.lang.StringBuilder.append(java.lang.String) : java.lang.StringBuilder [37]
 29  invokevirtual java.lang.StringBuilder.toString() : java.lang.String [41]
 32  astore_1 [test]
 33  iinc 4 1 [i]
 36  iload 4 [i]
 38  ldc <Integer 50000> [45]
 40  if_icmplt 13

where for each iteration of the loop(13-40) a new StringBuilder is instantiated and initialized with the result of the previous' loop StringBuilders value before appending the constant String just once each time. The optimized code results in this bytecode

 81  new java.lang.StringBuilder [24]
 84  dup
 85  invokespecial java.lang.StringBuilder() [62]
 88  astore 4 [builder]
 90  iconst_0
 91  istore 5 [i]
 93  goto 107
 96  aload 4 [builder]
 98  ldc <String "abc"> [35]
100  invokevirtual java.lang.StringBuilder.append(java.lang.String) : java.lang.StringBuilder [37]
103  pop
104  iinc 5 1 [i]
107  iload 5 [i]
109  ldc <Integer 50000> [45]
111  if_icmplt 96

in which the loop(96-111) just appends the constant String to the same StringBuilder each time which was created only once before the loop started. No copying around and creation of additional objects necessary, thus a huge performance-gain.

| | Comments (2)

As promised last time I'm presenting here the first in a series of Java Tips. To start easy I'll begin with one of the simplest tip to implement.


Advice

Use StringBuilder instead of StringBuffer.

Code-Example

Before

  StringBuffer str = new StringBuffer();
  str.append("foo");
  String x = str.toString();

After

  StringBuilder str = new StringBuilder();
  str.append("foo");
  String x = str.toString();

Benefit

Small performance gain. StringBuilder is a 1:1 drop-in replacement for the StringBuffer class. The difference is that the StringBuilder is not thread synchronized and therefore performs better on most implementations of Java. Even javac internally translates String x = "foo" + "bar"; into a StringBuilder operation (confirmed with Java 1.6.0_18). A small testcase

public static void main(String[] args) {
    long start = System.currentTimeMillis();
    StringBuffer buffer = new StringBuffer();
    for(int i = 0; i < 1000000; i++) {
        buffer.append("abc");
    }
    System.out.println("Time lapse using StringBuffer: " + (System.currentTimeMillis() - start) + " milliseconds");

    start = System.currentTimeMillis();
    StringBuilder builder = new StringBuilder();
    for(int i = 0; i < 1000000; i++) {
        builder.append("abc");
    }
    System.out.println("Time lapse using StringBuilder: " + (System.currentTimeMillis() - start) + " milliseconds");
}

using Java 1.6.0_18 shows that StringBuilder is roughly 100% faster than StringBuffer. Although on my machine this testcase keeps below 100ms for both with one million appends so this won't be the magical solution for most of your performance issues.

Remarks

Even if this tip can be applied in 98% of all cases one has to be sure that the String is used afterwards and the StringBuilder instance does not get passed between several threads. Since StringBuilder is not thread-safe this would be the only case where StringBuffer should be used. And of course it's not the silver performance bullet but just one slice in string-heavy applications.

|

Over the last ten (or so) days, just right for Easter, my health status went down again. I cought a small cold, not enough to keep me from working but bad enough so that I spent my non-work time in bed to recover faster. This helped somewhat in the way that it did not get worse anymore and today I'm not really feeling much of that issue anymore.

But this recovering was paid expensive. My spine aces returned, most probably caused by the lying-in-bed and limited exercising because of my injured ankle. Currently it's bad, not as bad as back in 2006, but still enough so that it causes me a constant pain in the lumbar spine. For now I just can fight this with pain killers but I know I need to get back to exercising as fast as possible to strengthen my muscles in this area again and get stabilized. Of course, I have to pay attention to the possible remainings of the cold and that I do nothing which could harm my wounded ankle.

Totally unrelated to this, some time ago I began collecting the different improvements I make to our sourcecode at work. I did this because I recognized, that I often applied the same improvements over and over again to other people's sourcecode and a lot of them are quite similar to each other. Most of this improvable code exists, because people just don't know that similar functionality already exists in common frameworks and so algorithms and operations get reingeneered again and again.

I plan to develop this collection so that each improvement has a before-after-example, a detailled explaination why this improvement is better, maybe a categorization into different areas (eg. Collections, Framework, Java5-Enhancement, etc.) and a difficulty-level. Maybe if this turns out well, I could also organize an internal training-event to spread this knowledge and raise the quality of our code just a tiny bit :)

Nevertheless, I'm also thinking of publishing each tip here in the blog for free availability and open discussion, so stay tuned if you're a Java developer, maybe there's also something in for you.

|

1

Archives