How to iterate over a Collection in Java?

Traditional way

List<Integer> numbers = ...

for (int i = 0; i < numbers.length(); i++) {
    if (i % 2 == 0) {
        Integer value = numbers.get(i);
        if (value % 2 == 0) {
            // do something to value

– an iconic way
– can access to both index and value at the same time

– too much code

– when you need to know the index of the element in a loop.

The Iterator way

In Java, Array and Collection all implement Iterable which returns an Iterator.

List<Integer> numbers = ...

for (Iterator<Integer> it = numbers.iterator(); it.hasNext();) {
    Integer value =;
    if (value % 2 == 0) {

If you need to know the index, use ListIterator (only work with List):

List<Integer> numbers = ...

for (ListIterator<Integer> it = numbers.listIterator(); it.hasNext();) {
    Integer index = it.nextIndex();
    Integer value =;
    if (index % 2 == 0 && value % 2 == 0) {

– supports iterator over all kinds of Collection types (Set, Queue, etc)
– can remove elements during iteration.
– faster than Tranditional way in case of LinkedList or other Collection implementation where random access is time-consuming.

– too much code

The Enhanced for way

This is the most recommended way since Java 5 if you just need to iterate over a Collection without the need to access to the index.

List<Integer> numbers = ...

// read as "for each number in numbers"
for (Integer number : numbers) {
    if (number % 2 == 0) {
        // do something with number


To iterate over an entire java.util.Map, please use this:

Map<String, Object> cache = ...

for (Map.Entry<String, Object> entry : cache.entrySet()) {
    doSomeThingTo(entry.getKey(), entry.getValue());

– simple, easy to read
– keep variables’ scopes clean (especially in nested loops)

– cannot access to the index of the element (well, not every time we need it actually)

The Java 8 way (or the function way or the lambda way)

In Java 8, Stream API has been introduce which makes it very easy to iterate and do somthing no elements of a Collection.

List<Integer> numbers = ...
    .filter(number -> numbers % 2 == 0)
        .forEach(number -> doSomething(number));

// or simply

numbers.forEach(number -> doSomething(number));

– easy to write and read
– method chain
– lazy evaluate

– the API has quite a lot of methods so it takes time to master all of them.

Why there is no SoftHashMap?

The above question bumped into me when I was developing a simple cache using java.util.Map. In the search for the answer, I came across a thread on JavaRanch that had the same question as mine. And there was an answer which had widen my knowledge in soft/weark references in Java.

I quoted the answer here in case the link is inaccessible.

In the few cases, where I used weak references (or soft references), I used the classes, (and queues) directly. Never used the WeakHashMap class. So, never thought about the possibility of the SoftHashMap class. IMO, the WeakHashMap class was written for internal (as support) reasons, and then exposed because others may need it. Maybe that is why SoftHashMap was never written.

In thinking about it a bit more, I don’t think that it is possible to write a SoftHashMap class. Remember that a SoftHashMap isn’t just a WeakHashMap that is using SoftReferences. It has to also not “distrurb” those soft references. Let me explain….

To implement a WeakHashMap, just use WeakReferences on the keys. This means, of course, that you need to do an additional deference to add/remove the key/value pairs. You will also need to attach a ReferenceQueue so that you can detect that a key has been GC’ed — which the WeakHashMap will use to automatically delete the key-value pair.

There is a minor flaw though — particularly if more than one key lands in a bucket. The WeakHashMap needs to deference the key (ie. make it a hard reference temporarily) so that it can use the hashCode() and equals() methods for the operation. This means, that in theory, it is possible for a key (that isn’t referenced by the application) to survive a GC cycle — if by chance theWeakHashMap is doing this operation….. This is probably not a big deal, as the chances are ridiculously low, and it can be picked up on the next GC cycle.

This becomes a major flaw with the SoftHashMap. Remember that SoftReference objects may or may not be GC’ed even if there are no hard references. It is at the whim of the JVM, which decides based on the amount of memory that it needs. The idea is, if there are lots of memory being freed, there is no reason to completely delete a cache that could be useful to the application.

The issue is, the SoftReference determines which instance to GC based on the access — it keeps timestamps of which object has been used and how recent (Least Recently Used). This means, that the temporary conversion of the soft reference to a hard reference (to do the equals()) will affect the LRU. A key that hasn’t been accessed by the application in a very long time, may survive a GC purely because it shares a bucket with a more commonly used key. And unlike the WeakHashMap issue, the chances are not low, and it may not be picked up in the next GC cycle.

Basically, you have a SoftHashMap that has soft references, but isn’t really a soft hash map.

Henry Wong

The link:

SQL isn’t dead. JooQ is a new fresh thing

After working with 3 layers, DAO, JPA and Hibernate and stuff, I think writing native SQL code is going to disappear. However, til today, I just found a new framework that support you to write SQL command by Java code. Their fluent API is so good that it seems identical with real SQL command.

Check out JOOQ – Java Object Oriented Querying;

P.s: Guess what! It’s type-safe.

Homeless Constants

Today, one of my colleague came to me and asked: “Hey, do we have a place to put a general constant?”. “What?” – I said. “A class, you know, to put all constants that do not particularly belong to anywhere”. Then I looked at him and said: “Dude, we got nothing such as general constants”.

The sad truth is, in our current project, we got a class named GeneralConstants just for putting all those constants in it. It got constants for entity String property lengths (seriously!!), panels’ names, bunch of constants that are irrelevant and only used exclusively with some specific modules. Even worse…

public final static String CLICKED = "CLICKED";
public final static String REMOVED = "REMOVED";

..and why stop if you can have

public final static String BLANK = " ";
public final static String COLON = ";";

It really got ridiculous to see:

String myName = firstName + GeneralConstants.BLANK
+ GeneralConstants.COLON + GeneralConstants.BLANK + lastName;

In my opinion, when you got a constant and wonder where you should put it for others to use. I got just a right place for it: inside the module using that constants and keep it private.

Not all constants are reusable and not all constants should be public. The first time you create a constant, keep it private inside your module and try real hard to encapsulate the use of it. If it really needs to be public, then it deserves its own place.

It should be EntityStringLengths

It should be InvokablePanels

It should be AllowedDialogActions

In case of BLANK and COLON, just use the fucking literal String. It is not making them reusable. It is overkill, too much fine-grained. They produces verbose & hard-to-read code. Moreover, doing this does not benefit you any performance. Please don’t do this.

Next time when you got a constant. Ask yourself:

  • Am I really going to use this constants somewhere else?
  • Could I encapsulate the use of this constants via methods?
  • What should I name the class containing the constant to make everybody know what it is?