Over a million developers have joined DZone.

Language Construct vs. Design Pattern - PHP Arrays In Java

DZone's Guide to

Language Construct vs. Design Pattern - PHP Arrays In Java

· Java Zone ·
Free Resource

Java-based (JDBC) data connectivity to SaaS, NoSQL, and Big Data. Download Now.

Automated migration is a difficult task because of many reasons. One of them is the need to ensure a good code quality for the generated code. Migrating from PHP to Java in particular is even more difficult, since the languages are so different in terms of execution models (interpreted vs. dynamic), type systems (loose-dynamic vs. strict-static) and so on.

The PHP Arrays Problem

A particular problem is the use of PHP associative arrays to build data structures, even if classes would have been a better choice. For constructing arrays, PHP provides a dedicated language construction, allowing the following:

$a = array("entry1",
"key2" => "entry2",
array("key31", "nested entry"));

The nTile PHP runtime library provides the Array and ArrayEntry classes to emulate this concept. However, by going the traditional way, the generated code can look overly complex in comparison:

a = new Array(new ArrayEntry("entry1"),
new ArrayEntry("key2", "entry2"),
new ArrayEntry(
new Array(
new ArrayEntry("key31",
"nested entry" ));

There are lots of things to deal with in building a software migrator from PHP to Java, so improving this wasn’t that high on our list of priorities. But then we remembered the fluid interfaces pattern, which we were already using with the Apache Commons Lang library.

Design pattern to the resque

In Java, one overrides the Object.equals(Object) to properly check object equality and the Object.hashCode() method when placing objects in hashtables. Coding them by hand is tedious and the EqualsBuilder and HashCodeBuilder classes of Commons Lang simplify the process, like in this case:

new EqualsBuilder()
.append(field1, rhs.field1)
.append(field2, rhs.field2)

As a consequence, we defined the ArrayBuilder class with the following signature:

public class ArrayBuilder<V> {
public ArrayBuilder() { }
public ArrayBuilder<V> put(Object key, V value) { }
public ArrayBuilder<V> put(V value) { }
public Array<V> getArray() { }

Using ArrayBuilder for the migration of the PHP code presented above is straightforward:

a = new ArrayBuilder<Object>()
.put("key2", "entry2")
.put(new ArrayBuilder<String>()
.put("key31", "entry3")

While the above code is still a bit more complex than the one in PHP, it provides the benefit of generics. This way it is easy to see that the array is supposed to hold all kinds of data, hence the Object generic parameter. And also that the array from the third entry will always contain strings. This information will also ease the transition to object-oriented data structures as the application evolves.


It is difficult to maintain the simplicity of a programming language, because one is tempted to add new constructs that ease certain tasks. We can see this happening with all the talk around the JSRs that should be made part of the Java 7 language specification. This is especially true for the language level XML support feature.

In this post I wanted to point out that this is not always the best approach. Sometimes changing the coding pattern is sufficient to solve your problems.

Connect any Java based application to your SaaS data.  Over 100+ Java-based data source connectors.


Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}