Hello Oracle Coherence

We can run Coherence just as we extract it from its distribution package, relying on its default configuration, but it is usually a smarter idea to provide at least some minimal custom setup for our instance.

We could pass parameters from the command line, or provide XML files with a format and name as expected by coherence.

Here is my tangosol-coherence-override.xml that I used to configure both my coherence server and client applications:

<?xml version='1.0'?>

<coherence xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
    xmlns="http://xmlns.oracle.com/coherence/coherence-operational-config"
    xsi:schemaLocation="http://xmlns.oracle.com/coherence/coherence-operational-
config coherence-operational-config.xsd">
    <cluster-config>
        <member-identity>
            <cluster-name>myc</cluster-name>
        </member-identity>

        <multicast-listener>
            <address>224.3.6.0</address>
            <port>9485</port>
            <time-to-live>0</time-to-live>
        </multicast-listener>
    </cluster-config>
</coherence>

All the specified fields should be immediate, maybe with the exception of time-to-live, that is the default surviving time for an object in the cache. As you could expect, zero does not mean "immediate death", but quite the opposite.

Using those configuration, we could finally start writing some Java code. You see that the resulting code is very clean and easy. From the programmer point of you, the cache is nothing more than a Map:

// ...
import com.tangosol.net.*;

// ...

    // setup
    CacheFactory.ensureCluster();
    NamedCache cache = CacheFactory.getCache("hello-example"); // 1

    // input
    String key = "k1";
    String input = "Hello World!";

    // put an item in the cache
    cache.put(key, input); // 2

    // get an item from the cache 
    String output = (String)cache.get(key); // 3
    if(output.compareTo(input) == 0)
        System.out.println("OK");

    // removing an item from the cache
    cache.remove(key);

    // terminate
    CacheFactory.shutdown();
    
// ...

1. There could be many different caches in out Coherence instance, we get the cache that the client want through a dedicated factory.
2. Just like a standard Map, we simply put key and value, and let Coherence to take care of the details. With a variant, we can pass a third parameter, the time to live in the cache for this element, in milliseconds.
3. As the standard Map, we should downcast to the actual type - beware of exceptions! And, if the key is not found, the result would be a null. I didn't check nor for unexpected type nor for null, real code should be more careful.

Go to the full post

Oracle Coherence setup

The current version of Oracle (previously Tangosol) Coherence, 3.7.1, is available for Java, .NET, and C++.

Starting up using the Java version is pretty easy. Go to the official Oracle Coherence download page, get the distribution file, unzip it on your file system and you are ready to start using it.

Server

Assuming you have a JVM 1.6.23 or newer, to run the Coherence server, you open a window shell, go to bin directory in coherence, and run the cache-server.cmd (for Windows) or cache-server.sh (for UNIX) script. The server, with a default configuration gets up.

I am currently running it on Windows, and it works fine. I tested it also on a UNIX box, and I had to slightly modify the script - I think I remember the issue was I had to use a bash shell (first line: #!/bin/bash)

Client

Once the server is up, you open another shell, go to the same coherence/bin directory, and you run coherence.cmd (or .sh for UNIX).

If you see that both server and client go up, you can proudly say you have Coherence working on your machine. Next step will be to create a simple hello application.

I guess you know it, but just in case, you can download also the official Oracle Coherence documentation.

Go to the full post

Google App Engine Setup

You can develop a web application for Google App Engine in Java, Python, and Go. I did it in Java, and here is a report of what I have done, from nothing till having a very simple web app running on appspot.com.

If you don't have any strong argument against Eclipse, it should a good idea to pick that IDE to develop for App Engine, and the reason is that Google makes available a plugin that would simplify a bit your job.

Currently are available plugins for Eclipse Europa, Ganymede, Galileo, Helios, and Indigo. You can install it directly from Eclipse, by the Software Update feature. If this does not work, firewall issues are a common reason for that, you can download the zipped plugin, and install it in Eclipse as a "New software".

Once the plugin is installed, we can run a testing version of the Google App Server locally. From the shell we go in a bit obscure directory, under eclipse\plugins, should be named something like:

com.google.appengine.eclipse.sdkbundle_1.6.1.v201112160242r37\appengine-java-sdk-1.6.1\

From there we can run the Application Server, in developing mode, passing to it as parameter the directory where it could find a .WAR file created for the Google App Engine.

For instance, to run the demo application Guestbook, we call:

> bin\dev_appserver.cmd demos\guestbook\war

You could have some error (again, a firewall issue could be the culprit), but if in the end you get the confirmation on the server going up and running on http://localhost:8080/, and:

The admin console is running at http://localhost:8080/_ah/admin

You are ready to open your favorite browser on localhost and see the test web application running locally.

Pay attention to the port number. If you run the server "by hand", as we have just seen, it is 8080, but when you run it from Eclipse the 8888 port number is used.

Go to the full post

SoftReference vs. WeakReference

At first sight SoftReference doesn't look much different from WeakReference. Actually, if you compare the example you can see here below, and the one I wrote for SoftReference, they will look almost identical.

What changes is all in the expected surviving time for an object that is not associated anymore to any strong reference. If it has at least one soft reference it should survive longer than if it had only weak references. We could say that the Java garbage collector turns a more gentle eye to soft references while it is stricter against weak references.

What it the point using soft references? Caching, maybe.

I loaded an object in memory, it has completed its job, and now it could be discarded. Still there is a chance someone will ask again for it soon, and loading it again is a bit expensive. We don't have a strong opinion on how long it should stay alive, and when it will be more worthy to get rid of it. We don't know how to take such a decision, so we let JVM deciding for us.

String strong = new String("A string");
SoftReference<String> soft = new SoftReference<String>(strong);

System.out.println("Setup: " + strong);
strong = null;

int[][] ia = new int[10][];
for(int i = 0; i < 10; ++i) {
    if(sa.get() == null) {
        System.out.println("Removed");
        return;
    }
    System.out.println(i + "] looping on " + sa.get());
    ia[i] = new int[150000];
}
System.out.println("Not removed!?");

If you run this code, and compare it with the same stuff but using WeakReference instead, you should find out a similar behavior, but a different number of loops performed before the garbage collector takes the decision to kill the object.

Go to the full post

WeakReference and WeakHashMap

As consequence of having a garbage collector that decides if and when an object is destroyed, there is no destructor in Java. Sometime this is a nuisance.

Think to this example. We need to keep references to some objects currently available in an application and associate to each of them some specific information. A map looks a natural container, but there is a problem: when we should remove a record from it?

When the object is not used anymore, one would say. But we are using Java, no destructor available.

We need a more creative solution, as for instance weak references. In this specific case we have even a better solution, WeakHashMap, a HashMap variation, seems exactly what we are looking for.

An example should make clear what a Java weak reference is, and how to use it:

String strong = new String("Weak"); // 1
WeakReference<String> wa = new WeakReference<String>(strong); // 2

System.out.println("Setup: " + strong);
strong = null; // 3

int[][] ia = new int[10][]; // 4
for(int i = 0; i < 10; ++i) {
    if(wa.get() == null) { // 5
        System.out.println("Removed");
        return;
    }
    System.out.println(i + "] looping on " + wa.get()); // 6
    ia[i] = new int[150000]; // 7
}
System.out.println("Not removed!?"); // 8

1. A "normal" reference to an object, is what in this context is usually called a "strong" reference. The garbage collector won't consider for destruction an object till it has at least one strong reference.
2. In this way we create a weak reference. It is not strong enough to save it from destruction by gc, but still provide a way to access the underlying object.
3. Setting a strong reference to null, we remove the connection between it and its original target. Now there is just a weak reference to our String object. Its life is in a serious danger, the garbage collector could decide to destroy it whenever it thinks it is the right moment.
4. The programmer can force the garbage collector the do its job, but I felt it was more interesting allocating some memory and let the JVM decide when to start to collect the garbage.
5. The WeakReference.get() method returns null when the referenced object has been deleted by gc.
6. Theoretically, gc could be called after (5) and before (6), so we could get and print "null" from our WeakReference. But do not expect to see this behavior.
7. The application claims for more memory, increasing the chance that the garbage collector would be called.
8. If you reach this line, the garbage collector has not be called when running the above for loop. Try to increase the quantity of memory claimed on (7).

Instead of using explicitly WeakReference, we could modify the above code and use WeakHashMap:

String key = new String("Key"); // 1
String val = new String("Weak hash map"); // 2

WeakHashMap<String, String> whm = new WeakHashMap<String, String>(); // 3
whm.put(key, val);

System.out.println("Setup: " + whm.get("Key"));
key = null; // 4

int[][] ia = new int[10][];
for(int i = 0; i < 10; ++i) {
    String stillThere = whm.get("Key"); // 5
    if(stillThere == null) {
        System.out.println("Removed");
        return;
    }
    System.out.println(i + "] looping on " + whm.get("Key"));
    ia[i] = new int[150000];
}
System.out.println("Not removed!?");

1. In a real case we usually have some more complex object instead a simple String, but for an example it would suffice.
2. Extra information related to the original object.
3. Our weak map where we store the original object as a key and the extra info as value.
4. The key variable does not refer anymore to the original String object. If we used an HashMap, we would still have there a strong reference to it, but we are using WeakHashMap that keeps just a weak reference to its keys.
5. If we used an HashMap, there wouldn't be much sense of looping in this way on get(), it would always return the same value. But here we are using a WeakHashMap, and this means that when the garbage collector is called, all the weak references to the removed object are marked as invalid (null).

Go to the full post

Logback filters

Filtering could be a complicated matter, the official Logback documentation would give you a detailed introduction to the subject, but I guess it can be useful having a more limited view on a few basic features.

We can specify the lower level accepted to log in a logger element (including the root element) setting its level attribute. For instance, if we want to log everything from trace up we specify "trace" as level for the root element:

<root level="trace">

A threshold filter could be used to skip from logging any message with a severity higher than the specified level. In this example a console appender is filtered to show only up to info messages:

<appender name="CApp" class="ch.qos.logback.core.ConsoleAppender">
    <filter class="ch.qos.logback.classic.filter.ThresholdFilter"> 
        <level>info</level>
    </filter>
    ...

We can filter so that only messages with a specified severity are logged. This filter accepts only warning messages and discard all the others:

<filter class="ch.qos.logback.classic.filter.LevelFilter">
    <level>WARN</level>
    <onMatch>ACCEPT</onMatch>
    <onMismatch>DENY</onMismatch>
</filter>

For more complex filtering we can create a custom filter and refer to it in our configuration file.

If we want to log only INFO, but just the ones among them containing the "hello" text in it, we could define a MyFilter class like this:

package test;

import ch.qos.logback.classic.Level;
import ch.qos.logback.classic.spi.ILoggingEvent;
import ch.qos.logback.core.filter.Filter;
import ch.qos.logback.core.spi.FilterReply;

public class MyFilter extends Filter<ILoggingEvent> {
    @Override
    public FilterReply decide(ILoggingEvent event) {
        if(event.getLevel() != Level.INFO)
            return FilterReply.DENY;

        if (event.getMessage().contains("hello"))
            return FilterReply.NEUTRAL;
        return FilterReply.DENY;
    }
}

In our configuration file we refer to it:

<filter class="test.MyFilter">

This approach keeps the XML configuration file simple, delegating the filtering logic to a custom Java class. On the other side, the configuration file gets a bit more obscure - at first sight it is not clear what the filtering is actually doing.

When the filtering rule is very simple, it won't probably make much sense using this approach, maybe a couple of filters in the XML configuration would be a better solution.

Go to the full post

Loggers and appenders

After performing some basic Logback configuration, we can see how to set appenders and loggers, so that Logback could send its output both to console and a file, specifying a different behavior in different classes.

We have already know how to use an appender to send output to the console, now we see how to create a file appender, and also how to create a configuration logger, to describe a relation between a SLF4J logger, as defined and used in our code, and an appender.

Here is an XML Logback configuration file:

<configuration debug="true">
  <statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener" />
  <appender name="CApp" class="ch.qos.logback.core.ConsoleAppender">
    <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
      <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36}: %msg%n</pattern>
    </encoder>
  </appender>
  <appender name="FApp" class="ch.qos.logback.core.FileAppender">
    <file>TestLogback.log</file>
    <encoder>
      <pattern>%date %level [%thread] %logger{10} [%file:%line]: %msg%n</pattern>
    </encoder>
  </appender>
  <logger name="test.TestLogback" level="info">
    <appender-ref ref="FApp" />
  </logger>
  <root level="trace">
    <appender-ref ref="CApp" />
  </root>
</configuration>

You see that this configuration file is set to be in debug mode, and it has a status listener element set to output its feedback to the standard console. More on Logback configuration debug in the previous post.
Same for the CApp appender, console appender already seen in the previous post.
The FApp appender is a FileAppender. We specify its name and the format internally used.
The logger element works like a root element, the biggest difference is due that root does not need a name, while a logger has to provide it, to be used by the SLF4J logger factory to retrieve the settings.
We can specify the additivity attribute in the logger, defaulted to true, if not explicitly set to false, it means that this logger uses the appenders specified by its ancestors (if any) and adds the one(s) specified in this element's belly. False means that all the existing appenders are discarded and only the one specified there are used.
The logger level is explicitly set to "info", this logger and all the ones on hierarchy below are affected by this.

We can get the same result by a groovy configuration file:

import static ch.qos.logback.classic.Level.DEBUG
import static ch.qos.logback.classic.Level.INFO
import ch.qos.logback.classic.encoder.PatternLayoutEncoder
import ch.qos.logback.core.status.OnConsoleStatusListener
import ch.qos.logback.core.ConsoleAppender
import ch.qos.logback.core.FileAppender

statusListener(OnConsoleStatusListener)

appender("CApp", ConsoleAppender) {
  encoder(PatternLayoutEncoder) {
    pattern = "%d{HH:mm:ss.SSS} [%thread] %-5level %logger{36}: %msg%n"
  }
}

appender("FApp", FileAppender) {
  file = "TestLogback.log";
  encoder(PatternLayoutEncoder) {
    pattern = "%date %level [%thread] %logger{10} [%file:%line]: %msg%n"
  }
}

logger("test.TestLogback", INFO, ["FApp"])
root(DEBUG, ["CApp"])

The lack of semicolons at the end of lines is a perlish Groovy variation on Java syntax.

Go to the full post

Autoscanning Logback configuration

A reason for breaking the decoupling between SLF4J and the underlying concrete logging framework is for changing the current log configuration without having to restart the application.

Logback has a feature that could be used to get a similar result leaving all the configuration stuff in a file. The idea is specifying in the configuration if Logback has to check again the configuration file and, if a change is detected, reload the properities.

This is achieved adding a couple of attributes to the configuration element for XML files (scan="true" scanPeriod="30 seconds" in my case, where I wanted to rescan the file each half minute - default value for scanPeriod is one minute).
For Groovy configuration we just have to add A call to scan("30 seconds").

I had a bumpy beginning of a relation with this feature, I couldn't make it work. But this was a good way to keep in touch with the internal Logback debug setting to get information on what was going.

Here is the XML configuration file that I used to test the autoscanning feature:

<configuration scan="true" scanPeriod="30 seconds" debug="true">
  <statusListener class="ch.qos.logback.core.status.OnConsoleStatusListener" />
  <appender name="capp" class="ch.qos.logback.core.ConsoleAppender"> 
    <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder"> 
      <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{40}: %msg%n</pattern> 
    </encoder> 
  </appender>
  <root level="all"> 
    <appender-ref ref="capp" /> 
  </root> 
</configuration>

The configuration element has three attributes, the first two ones for scanning and the third, named "debug", set to true, to let Logback giving debug feedback. I couldn't find how I could do the same in a Groovy configuration file (if someone knows, please, drop a comment).
Then I added a statusListener element specifying as associated class the one to send output to the standard console, and that was it.

Go to the full post

Configuring Logback

At startup Logback checks if there is a configuration file in the application classpath. First choice is logback.groovy, logback-test.xml and logback.xml are the fallback options. If none of these files is available, a default configuration is used, and the output is sent to standard console.

Here is an XML configuration file that would give a result close to the default.:

<configuration>
    <appender name="CApp" class="ch.qos.logback.core.ConsoleAppender">
        <encoder class="ch.qos.logback.classic.encoder.PatternLayoutEncoder">
            <pattern>%d{HH:mm:ss.SSS} [%thread] %-5level %logger{12}: %msg%n</pattern>
        </encoder>
    </appender>
    <root level="trace">
        <appender-ref ref="CApp" />
    </root>
</configuration>

The appender element describes a logging destination. Here the standard output console is used.
In the appender element is defined its associated encoder, where we define the pattern we want to use in the log generation.
The pattern describes a string where the first field is the time of current log line generation, the second is the thread name where the log was generated, the third is the log level, fourth is the logger name (with the max number of significative character that should be used - twelve is unreasonable low, but it could make sense in such a silly test). Finally we have the log message itself and a newline. The resulting pattern is very close to the default one.
The root element describes the root logger, that has a log level set to trace (instead of the default debug). The appender element inside root is where we can specify which appender (here CApp) should be used in this context.

It is easy to rewrite the same configuration with Groovy:

appender("CApp", ch.qos.logback.core.ConsoleAppender) {
    encoder(ch.qos.logback.classic.encoder.PatternLayoutEncoder) {
        pattern = "%d{HH:mm:ss.SSS} [%thread] %-5level %logger{12}: %msg%n"
    }
}
root(ch.qos.logback.classic.Level.TRACE, ["CApp"])

Similar structure, less verbose, and much more flexibility. The only issue is that we need Groovy in the application classpath.

Go to the full post

Breaking SLF4J decoupling

The main reason to use SLF4J as façade to the logging framework that we actually use is to decouple our Java application to the concrete logging system. That means that usually we won't make from our application any assumption on which actual logger framework is in the background.

But sometimes we need a more pragmatic approach. Besides, if we are using Logback, maybe we are not even interested in portability, and we are using SLF4J as interface because Logback is built to work in this way.

The need of changing the log level programmatically is one of those tasks that requires to delve in the actual logging framework details. It is not a common task, we usually prefer to use a configuration file, but maybe we can't afford to stop and start our application, so we have to be more creative than usual.
The SLF4J Logger does not have any visibility on it, we have to go down to the real logger object.

Firstly, let's write an utility method to check the current log level:

void checkLogging() {
    if(log.isTraceEnabled())
        System.out.println("Log trace enabled");
    else if(log.isDebugEnabled())
        System.out.println("Log debug enabled");
    else if(log.isInfoEnabled())
        System.out.println("Log info enabled");
    else if(log.isWarnEnabled())
        System.out.println("Log warn enabled");
    else if(log.isErrorEnabled())
        System.out.println("Log error enabled");
    else
        System.out.println("Log disabled");
}

The member variable log is defined in this way:

private static final Logger log = LoggerFactory.getLogger("test.TestLogback");

If this does not look clear to you, you could have a look to my previous post on how to set up a Java application to work with SLF4J and Logback.

We could change the logger level only for one specific logger, but here we changes the root logger level, to show, as a bonus, how the log level on an ancestor impacts on the current one when, as in this case, no specific log level is specified in the configuration file for it:

checkLogging(); // 1

org.slf4j.Logger sl = LoggerFactory.getLogger("root"); // 2
if(sl instanceof ch.qos.logback.classic.Logger) { // 3
    ch.qos.logback.classic.Logger cl = (ch.qos.logback.classic.Logger)sl; // 4

    cl.setLevel(Level.ALL); // 5
    checkLogging(); // 6

    cl.setLevel(Level.ERROR); // 7
    checkLogging();

    cl.setLevel(Level.OFF); // 8
    checkLogging();
}

1. The default log level for a Logback logger is debug.
2. The object returned is an SLF4J Logger, I defined it showing its class full name to stress this fact.
3. It comes handy here that Logback implements the SLF4J interfaces. To ensure that the concrete logging framework is Logback, we can just check the actual type of the logger retrieved from the logger factory.
4. We safely downcast the logger to the Logback specific type.
5. Enabling full logging for the root logger.
6. Root is an ancestor of any logger, our current logger, and no intermediate one, has explicitly set its log level, so the change of the root log level reflects directly on it.
7. Another change in root (and descendants) log level.
8. Log is disabled.

If you assemble this code in a your application you should get the same output I got:

Log debug enabled
Log trace enabled
Log error enabled
Log disabled

Go to the full post

Logback setup

Logback has been created to be the log4j successor, and designed as a native implementation of the SLF4J API - at least in its "classic" flavor. Its strong relation to SLF4J makes it probably the most interesting logger framework to couple with SLF4J.

It is easy start working with Logback. Once you have set SLF4J up in your developing environment, you have tested it with its native simple logger and maybe also with JUL, the JDK standard logger, Logback will be just a piece of cake.

Here is a minimal application that logs a message and then terminates:

package test;

import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class TestLogback {
    private static final Logger logger = 
        LoggerFactory.getLogger("test.TestLogback");

    public static void main(String[] args) {
        logger.debug("Hello from Logback.");
    }
}

I forgot to mention that slf4j-api-1.6.4.jar should be in the application classpath. If that was missing, you can't expect more than a spectacular failure:

Exception in thread "main" java.lang.NoClassDefFoundError: org/slf4j/LoggerFactory
at chapters.introduction.HelloWorld1.main(HelloWorld1.java:23)
Caused by: java.lang.ClassNotFoundException: org.slf4j.LoggerFactory
at java.net.URLClassLoader$1.run(Unknown Source)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
at sun.misc.Launcher$AppClassLoader.loadClass(Unknown Source)
at java.lang.ClassLoader.loadClass(Unknown Source)
... 1 more

Adding that jar to the classpath is not enough, though we have a slight improvement. SLF4J complains about no concrete framework available to do the real job:

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

Not knowing what to do, it defaults to the native no-logging plugin. Well, better than crashing.

We have to add to the application classpath another couple of JARs, Logback specific. To get them, we go to the Logback download page, download its compressed file (current latest version is 1.0.0) and expand it on your file system. The files we need to add to our classpath are logback-core-1.0.0.jar and logback-classic-1.0.0.jar.

The "classic" Logback JAR acts as a SLF4J plugin, working as an adapter from the SLF4J logging calls to the "core" Logback functionality. If no "core" is available, trying to run the application results in a crash:

Failed to instantiate SLF4J LoggerFactory
Reported exception:
java.lang.NoClassDefFoundError: ch/qos/logback/core/joran/spi/JoranException
at org.slf4j.LoggerFactory.bind(LoggerFactory.java:128)
at org.slf4j.LoggerFactory.performInitialization(LoggerFactory.java:108)
at org.slf4j.LoggerFactory.getILoggerFactory(LoggerFactory.java:279)
at org.slf4j.LoggerFactory.getLogger(LoggerFactory.java:252)
(...)

The SLF4J LoggerFactory was trying to instantiate the Logback logger, but in the middle of its job it found out that there was something missing in it, and so it had to (brutally) reject the request.

Go to the full post

Not logging could be expensive

We don't mind to pay a fair price in terms of execution time and storage when logging. But if we still have to pay a substantial price even when the logging is off, we could start to wonder about the quality of our logging system.

In the C/C++ world is relatively easy to keep such unwanted cost limited, using low level mechanism as macros and defines. Things are less immediate in the Java world, still we can achieve good results, if the logger is designed properly, as SLF4J shows.

There is a tiny cost that we can't avoid to pay for each logging call, regardless if the logging is currently enabled for the severity associated to the message or not, and that is the actual cost to check it. It looks quite unavoidable, if we want to keep the log configurable at execution time, and in any case it is just a cheap read and compare operation, so we could usually live with it.

But let's think to a case like this:

SomeComplicatedStuff scf;
// ...
log.debug("The value is: " + scf);

SomeComplicatedStuff is some class that provides an expensive toString() method. We don't mind to pay for its huge cost when debugging, but notice that firstly we build the message, implicitly calling SomeComplicatedStuff.toString() and only later, inside the logging method, we check if we actually should log it. Doesn't matter whether logging is active or not, we still pay for the call to the SomeComplicatedStuff toString() method.

A solution is duplicating the check on the log status:

SomeComplicatedStuff scf;
// ...
if(log.isDebugEnabled())
    log.debug("Log config file: " + logConfigFile);

It works, but this code is painful to write and maintain. It would be better to move the check in the logging methods and delay the string building after the check. Good news is that is the SLF4J approach. Bad news is that we have to rework the way the parameters are passed to the logging methods.

In the case above we were passing a String, created joining a constant one and a variable generated calling implicitly SomeComplicatedStuff.toString(). The logging method can't do anything to avoid the cost of calling toString(), it is just too late. We should have a way to delay the creation of the String to be logged after. The SLF4J decision is to design these methods like simplified String.print(). They have only one tag in the destination string, a couple of opening/closing curly brackets:

SomeComplicatedStuff scf;
// ...
log.info("Log config file: {}.", logConfigFile);

Doesn't look too bad, after all, but there are a couple of caveats.

1) Primitive values can't be passed to the logging methods.

This usually is a minor issue, if we are not afraid of the price of wrapping a primitive in an object. Besides, in Java 5 and above, autoboxing shields the process. Only if you are working with an ancient Java version you are forced to explicitly wrap your primitive value by the relative wrapper class.

2) No more than two objects can be passed as parameter to the logging string.

At first sight this look awful, but we can use the fact that Java arrays are objects, and pass all the objects that we want to be logged in a single array instance:

SomeComplicatedStuff scf1, scf2, scf3;
// ...
log.info("Values: {}, {}, {}", new Object[] {scf1, scf2, scf3} );

Not the most elegant piece of code ever seen, and even a bit counterintuitive, but it works.

Bear in mind that we get this behavior only when just one Object array is passed to a logger method. If a String and two Object arrays are passed, they are seen a two unrelated variables, and as such printed.

Go to the full post

System properties

I have the suspect that this is going to be one of the least interesting post of this blog, still I think that even on how to get system properties there is something interesting to be said, if one is in the right mood.

Actually, more than the act of getting the system properties itself, I found (sort of) interesting to spend a few words on the Java data type used to provide that information. Properties is an ancient Java class that went through some heavy redesign with the Java 2 revolution, where the Collection hierarchy was introduced.

It is easy to write a method that dumps to standard output the current system settings but, as we'll see, there is some juicy lines that could be written commenting it:

void dumpSystemProperties() {
    Properties props = System.getProperties(); // 1
    Iterator<Map.Entry<Object, Object>> it = props.entrySet().iterator(); // 2
    while (it.hasNext()) { // 3
        Map.Entry entry = it.next(); // 4
        String s = entry.getValue().toString(); // 5
        if(s.length() > 0)
            System.out.println(entry.getKey() + ": " + s);
    }
}

1. Asking to System to give us its properties is basically nothing more than this call. But what if we are not trusted enough to get them? A SecurityException would be what we get instead. If this code would be something more than an example in a blog, we should try/catch it. It is not mandatory to do that because SecurityException is-a RuntimeException, and Java won't complain for unhandled exceptions in this case, but in that unhappy case our code would brutally crash.
2. Having the properties available, usually we want to iterate on them. An alternative is represented by getting just one property, specified by its name, calling System.getProperty().
The Iterator is declared in an unusually complex way. Properties is-a Hashtable, a legacy collection pre-version 2 that we shouldn't use anymore in our code, but still available for the usual infamous compatibility reasons. In any case, Hashtable has been redesigned to be implemented in terms of Map. That leads to the fact that its key-value elements are now available as Map.Entry (internal interface of Map) instances. We know that both key and value are expected to be Strings but still we have to use a couple of Objects, again for compatibility.
Then we have to go through a call to entrySet() that provides us a view of the Properties as a Set, and on this set we can finally get our iterator.
3. Now we have a plain simple iterator, and we use it as we are accustomed to do, looping while there is a next.
4. As declared, the iterator returns a key-value pair, as a Map.Entry.
5. To have a bit of extra fun, I decided that I don't want to show the key associated to an empty value. Remember that value is an Object, so I convert it to a String before using it. I could have used a cast, and it should be safe by definition, still there is nothing bad in being a bit paranoic, so I used toString().

Go to the full post

JUL configuration

Once you have set SLF4J up, and done a bit of practice using the simple logger native plugin, you would probably start using it coupled to a "real" log framework, like the standard JDK logging facility, friendly known as JUL, from its fully qualified package name: java.util.logging.

To use JUL as logging framework in an application we have just to change the application classpath, removing the previous SLF4J plugin jar and adding slf4j-jdk14-1.6.4.jar instead. This is enough to SLF4J to get that JUL is our requested logging target.

By default JUL will use its default configuration. Usually we'd like to specify our specific configuration, let's see an example.

I wrote a very simple configuration file, named logging.properties, containing this few lines:

#test log
.level= ALL
handlers= java.util.logging.ConsoleHandler
java.util.logging.ConsoleHandler.level= ALL

An hash character, '#', has the same meaning of of a double slash in Java: consider whatever is after, till the end of line, as a comment.
In the second line we see how to specify the generic log level for the application: all the messages have to be generated.
The third line is about which handler have to be used. The console handler is a simple one that sends the log messages to standard error. By default it prints only messages with severity info and above.
In the fourth line we configure the console handler to manage all the messages, overriding its standard behavior.

It is not overkilling, we have to specify both that all the messages have to be generated (line 2) and managed by our handler (line 4).

A simple way to use a JUL configuration file is passing it to Java from the command line:

> java -classpath .;C:/slf4j-1.6.4/slf4j-api-1.6.4.jar;C:/slf4j-1.6.4/slf4j-jdk14-1.6.4.jar 
-Djava.util.logging.config.file=logging.properties test.MyLogTester

We asked java to run a class, test.MyLogTester, loading a file, logging.properties, as java.util.logging.config.file, so that it will be used to set the options for the JDK logger.

We can do the same programmatically. It could be handy to work in this way, for instance, to use different profiles without being forced to stop and restart the application:

Properties prop = System.getProperties();
prop.setProperty("java.util.logging.config.file", "logging.properties"); // 1
try { LogManager.getLogManager().readConfiguration(); } catch(Exception e) {} // 2

1. It doesn't make much sense to use an hard-coded file name, but this is just an example.
2. This error handling is very weak. We should have checked for IOException and SecurityException, and give some feedback to the user in case of failure.

A simple little method to check how the log behavior changes for different loggers and configurations:

void slf() {
if (!log.isTraceEnabled())
    System.out.println("Trace not enabled");
else
    log.trace("trace");

if (!log.isDebugEnabled())
    System.out.println("Debug not enabled");
else
    log.debug("debug");

if (!log.isInfoEnabled())
    System.out.println("Info not enabled");
else
    log.info("info");

if (!log.isWarnEnabled())
    System.out.println("Trace not enabled");
else
    log.warn("warn");

if (!log.isErrorEnabled())
    System.out.println("Error not enabled");
else
    log.error("error");
}

It is interesting to check if a log level is enabled before calling the relevant log message, so that we can have a different output when testing different configuration files.

Go to the full post

SLF4J SimpleLogger

We have seen how to setup SLF4J, the Simple Logging Facade for Java, and how to use its native SimpleLogger for start using it immediately.

This is a case where the name it is very close to the essence: the SLF4J SimpleLogger is actually a very simple logger. Still, it could be useful to spend some time exploring it in some detail.

There is something even simpler than SimpleLogger. If we don't want to have any log at all, we can use NOPLogger, implemented in the slf4j-nop-1.6.4.jar library (version number may vary). As its name suggests, each logging method in this class is implemented as a no-op. We can call them till we get blue in the face, still we won't generate anything.

Compared to it, SimpleLogger is not that extreme. To make it available to the project, we place slf4j-simple-1.6.4.jar in the specific Java Build Path. It probably makes sense using it only in very simple projects or some testing, as a temporary replacement for a real logger.

There is no way of configuring a SimpleLogger, we have to use it as it is:

• Only info, warn, and error message are generated;
• trace and debug methods are no-ops;
• the log message format is immutable;
• the log destination stream is System.err.

[Update: Since version 1.6.6, SLF4J SimpleLogger has gained more functionality. Please refer to the post written for the (currently) latest version, 1.7.5]

Go to the full post

SLF4J setup

The SLF4J acronym stands for Simple Logging Facade for Java. It is very similar to Apache Commons Logging (also known as JCL), of which it is kind of a successor.

SLF4J makes the Java code that uses it almost independent to the actual underlying log framework. In a tiny project this is usually not an issue, but especially when developing a library, or same other kind of modular code, that is meant be used by possibly unknown clients, this independence from the actual logging tool (Standard JDK, log4j, backlog, ...) could easily be a key factor.

Let's start form scratch, first step is downloading the library. You can find it on slf4j.org. At the time of writing this post, 1.6.4 is the latest available version.

SLF4J is provided as a compressed file, download it and expand it in some location available to your developer workspace. Then add the slf4j-api-1.6.4.jar (version number may vary) to the Java Build Path of your project.

Finally you can create, compile, and even run (with probably unexpected results) a simple SLF4J-based application:

// ...
import org.slf4j.Logger;
import org.slf4j.LoggerFactory;

public class HelloWorld {
    private static final Logger log = LoggerFactory.getLogger(HelloWorld.class);
    // ...

    public static void main(String[] args) {
        log.info("Hello World");

        // ...
    }
}

If you expected to get somewhere (on the standard output or error console would be a good guess) an hello message, well, you would be disappointed, because what you get is this:

SLF4J: Failed to load class "org.slf4j.impl.StaticLoggerBinder".
SLF4J: Defaulting to no-operation (NOP) logger implementation
SLF4J: See http://www.slf4j.org/codes.html#StaticLoggerBinder for further details.

Thinking better we should admit that SLF4J is right. It doesn't know which logging framework to use, it doesn't even know if we would like to see any feedback or that would be terribly embarrassing. So it assumes it is better to be silent, and uses a default no-op implementation (slf4j-nop-1.6.4.jar) that simply eats up any log we send to it.

If we want to have a basic feedback, so that we could see if anything is working as expected, we can use a simple logger provided by SLF4J. We just have to add the library slf4j-simple-1.6.4.jar to our application Java Build Path. Now we should get from our application a better output:

0 [main] INFO HelloWorld - Hello World

That's it. SLF4J is up and running. As we have seen, it is very easy to switch to a different logging framework, just change a jar in the build path. Removing the SLF4J native simple logging framework and adding slf4j-jdk14-1.6.4.jar (native SLF4J plugin to the standard JDK logger, also known as JUL: java.util.logging) it is all we need to make our application ready to run and producing a JDK log:

06.12.2011 18:48:30 HelloWorld main
INFO: Hello World

Go to the full post

Cloning a Collection

The Collection Java interface, root of all the standard Java collections does not support cloning. If we are working with a collection without knowing its actual type, we can bypass this issue converting it to an array.

If we really want to create a shallow copy of our collection we have to engage ourselves in writing a piece of kind of dirty code involving a safe downcast to the actual type of our collection and then an upcast back to the Collection interface.

As example, let's create an ArrayList of Integers and add a few items to it:

Collection c = new ArrayList(3); // 1
c.add(1); // 2
c.add(2);
c.add(3);

1. Following the good practice of working with abstractions whenever it is possible, we create an ArrayList, specifying Integer as underlying type and then we assign its address in memory to a Collection interface. I have even specified the number of expected elements, so that the ArrayList is created of the right size, avoiding memory waste or the need of (automatically) resize the collection.
2. An int is passed to add(), thanks to autoboxing, it is automatically boxed in the relative wrapper type.

A Collection object can't be cloned, so let's downcast it:

if(c instanceof ArrayList) { // 1
    Collection c2 = ((Collection)((ArrayList)c).clone()); // 2
    // ...
}

1. Better playing safely, before downcasting we explicitly check the actual collection type, in this way we don't have to try/catch this code for always possible bad casting.
2. Here we know that the actual type of our collection is indeed an ArrayList, so we downcast it and call the ArrayList.clone() function. Still we usually want to going on working with a Collection interface.

Go to the full post

Solving systems of linear equations

In the Java Apache Commons Math library there is a package, linear, that is about Linear Algebra. There we could find support to manage systems of linear equation.

A very simple linear system, as shown in the above quoted wikipedia page, features two equations and two variables:

2x + 3y = 6
4x + 9y = 15

Let's solve it through Apache:

RealMatrix coeffs = new Array2DRowRealMatrix(
        new double[][] {{2, 3}, {4, 9}}, false ); // 1
DecompositionSolver ds = new
        LUDecompositionImpl(coeffs).getSolver(); // 2

RealVector consts = new ArrayRealVector(
        new double[] {6, 15}, false ); // 3
RealVector sol = ds.solve(consts); // 4
System.out.println(sol);

1. We create an Array2DRowRealMatrix object passing to it our coefficients as a bidimensional array of double. The second parameter, set to false, says to the ctor not to bother making a local copy of the array, but use it directly. We won't care of the actual matrix type, so we store the result in the interface RealMatrix, root of a hierarchy of matrices including also an implementation for sparse matrix (OpenMapRealMatrix).
2. We should decide which algorithm use to solve the system. Here the chosen one is the LU decomposition. See the Apache documentation for the available alternatives (Cholesky, QR ...). Notice that here we need just to get a solver from the decompositor, so it is created and then forgotten at the end of the same line. But its solver survives and it is kept as a DecompositionSolver interface.
3. Very similarly to (1), we create an ArrayRealVector object for the constants, without copying the double raw array created on the fly, and keep it as a RealVector interface.
4. Calling DecompositionSolver.solve() for the constants vector we get a vector containing the solution. If there is no solution we get an exception instead. So it would be better to try/catch all this code (also the Array2DRowRealMatrix ctor throws unchecked exceptions) to avoid unpleasant surprises. It is easy to make this code crashing. Just change the coefficients and constants so that the system has no solution - just think to the geometrical interpretation of this system, remember that there is no intersection between parallel lines, and try to solve a system where:

RealMatrix coeffs = new Array2DRowRealMatrix(
        new double[][] {{2, 3}, {4, 6}}, false );
RealVector consts = new ArrayRealVector(
        new double[] {6, 12}, false );

You will get instead of a solution a SingularMatrixException.

We can extract from a RealVector the underlying raw double array:

double[] dv = sol.getData();
for(double d : dv)
    System.out.print(d + " ");
System.out.println();

But we can even get rid of all the RealVector objects above, and use directly just raw arrays:

// ...
double[] consts = new double[] {6, 15};
double[] sol = ds.solve(consts);

for(double d : sol)
    System.out.print(d + " ");
System.out.println();

Go to the full post

More random generators

If we need a sequence of pseudo-random numbers in Java we could use the java.util.Random class. For simple requirements this would suffice, but when the game gets tougher it should be worthy have a look at the generators provided by the Apache Commons Math library.

If we want to fill up an array of integer with a random sequence of one digit numbers, we could write:

Random rg = new Random();
rg.setSeed(System.currentTimeMillis()); // 1

for (int i = 0; i < ia.length; ++i) // 2
    ia[i] = rg.nextInt(10); // 3

1. The generator is initialized using the current timestamp. 2. "ia" is an array of integer, supposed to be properly initialized. 3. Each element in the array is set to a random number extracted from the interval [0,9]. For testing purpose it is useful to generate always the same sequence, to do that we can rewrite (1) to set the seed to a constant value:

rg.setSeed(42);

Apache Commons Math makes available a wrapper class that makes handier working with the standard random generator, letting us to easily change the generator to more advanced ones - provided by the library itself or created by ourselves.

RandomData rd = new RandomDataImpl(); // 1
for (int i = 0; i < ia.length; ++i) {
    ia[i] = rd.nextInt(0, 9); // 2

1. The current time is used to seed the generator, if we want to force using a specific seed we should call RandomDataImpl.reSeed(). Unfortunately this method is not part of the RandomData interface, so if we want this functionality be available we are forced to work with the concrete type. 2. Here nextInt() is more flexible, we specify both limit of the interval of values generated (besides, here the last one is included, in the java.util.Random it is excluded). Moreover, this method throws an exception if the second parameter is not bigger than the first one. One last notation, there is no check on the positiveness of the passed parameters (the standard Random throws a IllegalArgumentException if we pass a negative value), but the algorithm is not expected to works correctly for negative values. If we write the code using the Apache wrapper class, we can easily swap the random generator, using an overload of the constructor. So, to use the generator based on the Mersenne Twister instead of the JDK standard, we just have to rewrite (1) in this way:

RandomData rd = new RandomDataImpl(new MersenneTwister());

The Mersenne twister is one of the handful of generator based on the WELL family provided out of the (Apache) box.

Go to the full post

OLSMultipleLinearRegression parabola

We know how to infer a first degree curve (i.e. a straight line) from a bunch of observations using the Ordinary Least Squares estimator provided in the Java Apache Commons Math package.

Things are getting a bit more complicated here, as we try to get as estimation a second degree curve (a parabola).

Assuming that "ols" is a previously defined OLSMultipleLinearRegression object, here is the code that sets its sample data and then extract the relative coefficent estimation:

int vars = 2; // 1
int obs = 3; // 2
double[] data = { 4, 1, 1, /**/ 8, 2, 4, /**/ 14, 3, 9, }; // 3

ols.newSampleData(data, obs, vars); // 4

double[] coe = ols.estimateRegressionParameters();
dumpEstimation(coe); // 5

1. The number of independent variables for a parabola should be 2.
2. As before, we should provide at least one observation more than the vars.
3. Here is the input data. First component is y, than we have x, and then x square. These observations are lazily taken calculating y = x^2 + x + 2, as you could have guessed, so we would expect to get back as coefficients values close to (2, 1, 1).
4. I didn't try/catch, assuming that the caller of this code would do that for me. Actually, all the exceptions thrown by this package are unchecked (derived from RuntimeException), so we are not forced to try/catch or declare them in the method signature - and we can simply accept the risk of a sudden death of our application.
5. We have seen this little testing function in the previous post, it works fine here too.

Does the flattened data array bother you? Maybe not in this so simple example, but in a more real scenario could be cumbersome to organize data accordingly to this model. It could be useful to place y's in a unidimensional array, and x's in a separate bidimensional one. There is a OLSMultipleLinearRegression.newSampleData() overload that works right in this way:

double[] ys = { 4, 8, 14 };
double[][] xs = new double[][] { {1, 1}, {2, 4}, {3, 9} };
ols.newSampleData(ys, xs);

double[] coe = ols.estimateRegressionParameters();
dumpEstimation(coe);

This piece of code should be equivalent to what we have seen above.

Go to the full post

The simplest OLSMultipleLinearRegression example ever

Assuming that the reader knows what Multivariate Linear Regression by Ordinary Least Squares is, and that he would like to use it in Java by means of OLSMultipleLinearRegression, class that is part of the Apache Commons Math library, let's see the simplest example of its usage I could think of.

I have two observations, one variable, and I want to get the description of an interpolating curve:

OLSMultipleLinearRegression ols = new OLSMultipleLinearRegression();

double[] data = { 2, 1, 4, 2 }; // 1
int obs = 2;
int vars = 1; // 2
try {
    ols.newSampleData(data, obs, vars); // 3
}
catch(IllegalArgumentException e) {
    System.out.print("Can't sample data: ");
    e.printStackTrace();
    return;
}

double[] coe = null;
try {
    coe = ols.estimateRegressionParameters(); // 4
}
catch(IllegalArgumentException | InvalidMatrixException e) { // 5
    System.out.print("Can't estimate parameters: ");
    e.printStackTrace();
    return;
}

dumpEstimation(coe);

1. The input data is flattened in an array, where all the observations are stored one after the other, respecting the convention of having first the y and then the x component.
2. We should have more observations than variables, so this is the minimal case. Having just one variable, we'll get a straight line as a result.
3. The functions performs a few check on the passed data before working with them, if the number of variables is not bigger than the number of observations, or if there are less values than expected in the array, an IllegalArgumentException is thrown.
4. The resulting curve parameters are returned in a double array. In case of failure an exception is thrown.
5. Cool Java 7 feature, we can group all the exceptions that requires the same management in a single block. In previous Java version, a specific catch is required for each exception type.

The last line is a call to a testing function that gives some feedback to the user. It calls another short function that actually calculates the estimated y value given a specific x:

private void dumpEstimation(double[] coe) {
    if(coe == null)
        return;

    for(double d : coe)
        System.out.print(d + " ");
    System.out.println();

    System.out.println("Estimations:");
    System.out.println("x = 1, y = " + calculateEstimation(1, coe));
    System.out.println("x = 2, y = " + calculateEstimation(2, coe));
    System.out.println("x = 3, y = " + calculateEstimation(3, coe));
    System.out.println("x = 4, y = " + calculateEstimation(4, coe));
}

private double calculateEstimation(double x, double[] coe) {
    double result = 0;
    for(int i = 0; i < coe.length; ++i)
        result += coe[i] * Math.pow(x, i); // 1
    return result;
}

1. The most interesting line in this testing code. It shows how the coefficients are stored in the array returned from OLSMultipleLinearRegression.estimateRegressionParameters(). As we see, the coefficient 'i' is relative to the 'i'-th power of x.

The expected output is:

-0.0 2.0 
Estimations:
x = 1, y = 2.0
x = 2, y = 4.0
x = 3, y = 6.0
x = 4, y = 8.0

Go to the full post

From array of primitives to Collection

Say that you are working with some Java code, and you have in your hands an array of doubles. For some reason, you need to access that data as a Collection. How could you do that?

If instead of a primitive type you had an array of objects the solution would have been pretty easy. In the Arrays utility class there is a method exactly tailored for this use, asList(), that creates a new ArrayList collection out of a passed array. But in this case you have to work a bit more.

Firstly, let's see how Arrays.asList() works:

String[] sa = { "one", "two", "three" };
Collection<String> sc = Arrays.asList(sa); // 1
System.out.println("Max is: " + Collections.max(sc)); // 2

1. As promised, it was very easy indeed.
2. And now we can use the utility methods!

It is a pity, but we can't do the same for an array of primitive values:

double[] da = { 1d, 2d, 3d };
Collection<Double> dl = Arrays.asList(da); // 1 !!! error !!!

1. Sadly we have a "Type mismatch: cannot convert from List<double[]> to List<Double>".

Here autoboxing (that useful feature available from Java 1.5 that automatically converts any primitive type to its matching wrapper type) is not working, and for a good reason: performance for huge array conversions. If you really need to box an array of primitives you have to do it explicitly.

Collection<Double> dl = new ArrayList<Double>(da.length);
for(double d : da)
    dl.add(d);
Double max = Collections.max(dl);
System.out.println("Max is: " + max);

Go to the full post

SummaryStatistics vs. DescriptiveStatistics

Apache Commons Math makes available the classes DescriptiveStatistics and SummaryStatistics, both derived from the interface StatisticalSummary (there are a few more classes in the same hierarchy, that are not in this post spotlight). Both of them are used to get basic univariate statistics, but there are a few reason that should help us to decide which one is the most suitable for a specific task.

Let's start talking about commonality. Both of them are not synchronized, if you really need a thread-safe implementation, check out for SynchronizedDescriptiveStatistics and SynchronizedSummaryStatistics, and both of them implement all the basic functionality defined in StatisticalSummary.

It is a handful of methods that should look pretty straightforward to the reader having just some basic statistics knowledge:

double getMean(); // arithmetic mean
double getVariance();
double getStandardDeviation();
double getMax();
double getMin();
long getN(); // number of available values
double getSum(); // sum of the values

All this methods return NaN when called if no values have been added to the object, with the obvious exception of getN() that returns 0.

The substantial difference is that SummaryStatistics does not store data values in memory, resulting being sleeker and leaner than DescriptiveStatistics. On the other hand, DescriptiveStatistics makes available some more functionality to the user. So, if what you need is in StatisticalSummary, you can manage huge collection of data with SummaryStatistics and happily avoid to pay a large price in terms of memory usage.

There are then a few common methods that are defined for both SummaryStatistics and DescriptiveStatistics, even though they are not part of the commonly implemented interface StatisticalSummary.

To load the data we use public void addValue(double value), that could be called like this, where generator is a Random object previously initialized:

for(int i = 0; i < 1000; ++i) {
    stats.addValue(generator.nextDouble());
}

From object of both classes we can get the sum of the squares, getSumsq(), and the geometric mean, getGeometricMean(). Sometimes it is useful to reset the values on which we are working, and this is done by calling clear().

Only for SummaryStatistics are defined getSumOfLogs() and getSecondMoment().

Only for DescriptiveStatistics are available:

void removeMostRecentValue(): discards just the last value inserted in the underlying dataset or throws an exception.
double replaceMostRecentValue(double v): replaces the last inserted value or throws an exception.
double getSkewness(): the skewness is a measure of the current distribution asymmetry.
double getKurtosis(): the kurtosis is a measure of the current distribution protrusion.
double[] getValues(): creates a copy of the current data set.
double[] getSortedValues(): creates a sorted copy of the current data set.
double getElement(int index): gets a specific element or throws an exception.
double getPercentile(double p): an estimation of the requested percentile, or throws an exception.

Window size

When we have no idea of how many values could be entered, it could be dangerous using DescriptiveStatistics in its default mode, that let the underlying data collection growing without any limit. Better to define the dimension of the "window" we want to work with using setWindowSize(int windowSize). What happens when we reach the limit is that the oldest value is discarded to let room for the new entry. If you wonder what is the current size, you can check it through getWindowSize() that returns, as an int, its current value. The "no window" value is represented by DescriptiveStatistics.INFINITE_WINDOW, defined as -1.

Go to the full post

Random expectation

There is not much one could reasonably say about a single random extraction. But we have a more defined expectation on the mean of a series of random extractions.

The Java Random class makes available a few different pseudo-random distribution from which we can extract variables and play with them. Here we are going to use values returned by nextDouble(), method that returns a value picked up from a uniform distribution between 0.0 and 1.0, and nextGaussian(), that refers to a Gaussian ("normal") distribution with mean 0 and standard deviation 1.

To spice things a bit, we will also manipulate the gaussian values to get a square gaussian distribution.

The mean for the variables generated from Random.nextDouble() should tend to 0.5, as we should find out running a few times this function with increasing values of "n":

double expectU(int n) {
    double sum =0;
    for(int i =0; i < n; ++i)
        sum += generator.nextDouble();
    return sum/n;
}

Doesn't change much for Random.nextGaussian(), but that it should tend to a mean of 0.0:

double expectG(int n) {
    double sum =0;
    for(int i =0; i < n; ++i)
        sum += generator.nextGaussian();
    return sum/n;
}

A bit more interesting the square gaussian case, since we provide an adaptor from Random.nextGaussian():

double squareGaussian() {
    return Math.pow(generator.nextGaussian(), 2);
}

double expectSG(int n) {
    double sum =0;
    for(int i =0; i < n; ++i)
        sum += squareGaussian();
    return sum/n;
}

In this last test we should see how, for increasing values of n, the resulting expected mean value should tend to 1.0.

Go to the full post

Using random to generate pi

It could look counterintuitive, but we can use a pseudo-random, uniformly distributed, sequence to find out pi. One could asks why on the Earth we should do something like that when any reasonable programming environment provides it off the box - in Java it is a constant in the Math class, Math.PI a double set to 3.14159265358979323846, as one could expect.

OK, forget about the how much it looks reasonable to calculate pi in this way, what it is interesting it is the general idea behind.

Think to a square with a circle inscribed in it. The area of the circle is pi*radius*radius. The area of the square is (2*radius)*(2*radius).

Now think to throw arrows to the square. Assuming the result is an homogeneous distribution, we should get that the ratio between the arrows inside the circle and all the arrows that reached the square should be the same of the ratio between the areas of the two figures.

So: pi*radius*radius / (2*radius)*(2*radius) = arrows in the circle / arrows in the square

It should be easy to get from that: pi = 4 * arrows in the circle / arrows in the square

Let's implement it in Java, simplifying it a bit working on just a quarter of the circle and square, so that we would use just values in the 0, 1 interval:

import java.util.Random;

public class RandomPi {
    private Random generator;

    public RandomPi() {
        generator = new Random(System.currentTimeMillis()); // 1
    } 

    public double pi(int n) { // 2
        int hit = 0;
        for(int i = 0; i < n; ++i) {
            double x = generator.nextDouble();
            double y = generator.nextDouble();

            if(Math.sqrt(x*x + y*y) < 1) // 3
                ++hit;
        }        
        return 4.0 * hit / n; // 4
    }
}

1. The random generator is initialized passing the current time, so to have a different sequence for each run of this application.
2. Our pi generator asks in input for the number of "arrows" that we throw. Be prepared of using an high value to get a reasonable approximation.
3. If the distance of the randomly generated coordinates from the center (0, 0) is less than 1, the arrow is in the circle, so we increase the counter.
4. We apply our formula, as seen above. We explicitly use 4 as a double value, otherwise we would have a division between integers, giving as result an integer, hardly what we really want.

Go to the full post

From Collection to array

The Collection interface, root of the Java Collection hierarchy, does not support cloning. That means that we can clone a concrete class, but we can't do it if we don't know the actual type of the collection.

We can overcome this issue by a couple of overloaded Collection.toArray() methods.

If we have an heterogeneous Collection, we can convert it to an array of Object, and then accessing any element checking what is its real type:

Collection<Object> oc = new HashSet<Object>();
oc.add(42);
oc.add("Deep Thought");
// ...

Object[] oi = oc.toArray();

for(Object o : oi) {
    if(o instanceof Integer) {
        if((Integer)o == 42) {
            // ...
        }
    }
    else if(o instanceof String) {
        if(((String)o).startsWith("Deep")) {
            // ...
        }
    }
    // ...
}

We pay the handiness of having a tutti-frutti collection with the ugliness of checking the instance type before being able to use an element. The array copy can't do much more than keep the same behavior for its elements.

But using the same toArray() method when dealing with an homogeneous Collection is a pity.

Collection<Integer> ic = new HashSet<Integer>();
ic.add(42);
// ...

Object[] oa = ic.toArray();
if(oa.length > 0 && (Integer)oa[0] == 42) { // !!!
    // ...
}

We must cast the element to the right type even if we already know that each element of the array is of that specific type. We can avoid this by using the other toArray() overload:

Integer ia[] = new Integer[ic.size()]; // 1
ic.toArray(ia); // 2
if(ia.length > 0 && ia[0] == 42) {
    // ...
}

1. Allocate memory for the array
2. Pass the array to toArray(), it simply fills it with the elements in the collection.

If we pass to toArray() an array shorter than expected, it allocates memory for a new array of the right size. The most valuable information we are passing to toArray() is the type we want to be used.

But what if we pass a wrong array type? As you could suspect, an exception would be thrown.

Collection<String> ic = new HashSet<String>();
// ...

Integer[] ia = new Integer[ic.size()]; // mistake!
try {
    ic.toArray(ia); // exception
}
catch(ArrayStoreException e) {
    // ...
}

Go to the full post

String, StringBuffer, StringBuilder

The Java most natural class to deal with character strings is String. But you should be aware that its instances are immutable objects so, when some mutation is required, better to use StringBuffer or StringBuilder, when no synchronization is required.

I recently bumped in some code like this:

Properties p = new Properties(); // ?!
p.put("A", aString);
p.put("B", bString);
p.put("C", cString);
String x = "Current relevant parameters: " + p;
// ...

A creative, and unexpected, usage of Properties as an string formatter helper. There are here a couple of issues that should be considered. Firstly, the casual code reader could be puzzled by seeing a Properties object here. It is usually better writing code that is more readable, and using such a connotated class out of context doesn't look ideal. Secondly: performances. Properties class is not designed for string manipulation, so we shouldn't expect it being especially fast.

If we really want to use a collection in this way, it would be better to get a less specialized class, probably HashMap:

Map<String,String> p = new HashMap<String, String>();
p.put("A", aString);
p.put("B", bString);
p.put("C", cString);
String x = "Current relevant parameters: " + p;
// ...

This solution is substantially faster, and could replace the original implementation, if we don't mind about the loss of ordering in the values. Besides, notice the common practice of working with an interface (Map) instead of a concrete class (HashMap).

In any case, it would be better to use String, both from a logical point of view and performance-wise:

String s = "Current relevant parameters: {";
s += "A=" + aString + ", ";
s += "B=" + bString + ", ";
s += "C=" + cString + '}';

Still there is a performance bottleneck due to the immutable and thread-safe nature of String. Being immutable, each time we think we are changing the content of a String instance, we are actually creating a new String object and discarding the old one. Being thread-safe, each time we operate on it, a lock is used to ensure synchronization.

Using mutable StringBuffer would make our code a bit faster:

StringBuffer sb = new StringBuffer(150); // 1
sb.append("Current relevant parameters: {");
sb.append("A=").append(aString).append(", "); // 2
sb.append("B=").append(bString).append(", ");
sb.append("C=").append(cString).append('}');
String x = sb.toString(); // 3

1. Setting the initial capacity to the expected length of the resulting string saves some extra time otherwise spent resizing.
2. StringBuffer.append() returns a reference to this object, this is useful to chain multiple calls to methods of the same object, making the code more readable (well, this point could be questionable).
3. StringBuffer is unrelated to String, an explicit conversion is required.
If we can assume we are already in a thread safe part of our code, we can shift to the faster StringBuilder class:

StringBuilder sb = new StringBuilder(150);
sb.append("Current relevant parameters: {");
sb.append("A=").append(aString).append(", ");
sb.append("B=").append(bString).append(", ");
sb.append("C=").append(cString).append('}');
String x = sb.toString();

It looks just the same of StringBuffer, the difference is all under the hood, no synchronization is done.

I have done an approximative performance check, and I have found, as expected, that StringBuilder is the fastest solution. StringBuffer is 33% slower; String 50%; HashMap 100%; and using Properties is worse of more than a whopping 200%.

In brief, we could extrapolate a couple of guidelines:

• use a class for what it is meant;
• locking is expensive, don't do it if you don't need it.

Go to the full post

Shallow copy vs. deep copy

The copy of a value variable is a simple concept. If we say that 'b' is a copy of variable 'a', we mean that the value stored in 'a' has been copied to the memory location reserved for 'b'.

Pointer variables require a clarification. Do we want the copy to be just an alias, so that the address stored in the memory location refers to the same object pointed by the original (shallow copy), or to be a completely new object, a logical copy of the original (deep copy)?

As we can imagine, shallow copy has the advantage of being fast and simple, on the other side we should be well aware that we are dealing with just an alias for the original object, and not a real new different one.

Deep copy is more complicated to be achieved, requiring to be expressly tailored on the actual class it is going to impact, but it gives us a real new object that could be used independently from the original one.

Besides, there are a few more details that are specific to Java. Let's see some of them.

Shallow copy through Object.clone()

The base class of the Java hierarchy, Object, has a method, clone(), that could be used to perform a shallow copy. So we should expect that any Java object could be cloneable, but this is actually not true, we have to explicitly takes a couple of actions in our class, if we want that.

• We have to override Object.clone(), changing its visibility. Object.clone() is declared protected, we can't actually call it for an Object instance.
• We have to declare that our class implements the Cloneable interface. Otherwise a call to Object.clone() would throw an exception.

Arrays are cloneable

Let's write a silly little class that wraps an integer value:

class WrInt {
    public WrInt(int v) { value = v; }
    public int value;
}

An object of this class can't be cloned, since the class is not Cloneable and there is no clone() method public override.

But we can clone an array of its objects:

WrInt w1[] = { new WrInt(0), new WrInt(1), new WrInt(2) };
WrInt w2[] = w1.clone();

Now we can change an element in the first array, and see that this change could be observed also from its clone:

w1[2].value++;
System.out.print(w1[2].value + " == " + w2[2].value);

The clone() method called on an array takes care of allocating memory for another array with the same size of the original one, and then (shallow) copying each element in the destination. We could get the same result in this way:

WrInt w3[] = new WrInt[w1.length];
System.arraycopy(w1, 0, w3, 0, w1.length);

The System.arraycopy() performs a (shallow) copy from an array (w1, here) starting at a specific position (0) to a second array (w3) starting at the given position (0), looping for a number of times (the length of w1). It is our responsibility to ensure that we are passing valid parameters to arraycopy(), in case of mistakes we should expect an exception.

Is there a way of combining the elegance of clone() and the handiness of System.arraycopy()? Actually, yes. Since version 1.6 the utility class Arrays has been extended to include copyOf() that performs the (shallow) copy of an array creating on the spot a clone, and letting us to use the flexibility of arraycopy().

Here is an example:

WrInt w4[] = Arrays.copyOf(w1, w1.length);

Performing a deep copy is a tad more complicated. We are responsible to correctly allocate memory, and to specify how and where the copy has to be done.

Here is a deep copy of our original array:

WrInt w5[] = new WrInt[w1.length];
for(int i = 0; i < w5.length; ++i) {
    w5[i] = new WrInt(w1[i].value);
}

Each element of the new array has to be explicitly constructed from the correspondent original one.

Immutable

OK, but why we have used that WrInt custom class instead of standard types? We know that it wouldn't make sense to use primitive types (int, double, ...) since they are value types. But what about the wrapper classes (Integer, Double, String, ...)?

The fact is that they are immutable, so we do not get any advantage in performing a deep copy when they are involved. The strange effect we have is that the two twin arrays generated by shallow copy are identical till we perform a change on one element on whichever one. At that point, the item we change is substituted with a new immutable instance breaking the identity with its clone, that keeps the reference to the old element.

Go to the full post

null does not mean false

A special value is used as marker when a pointer does not refer to a valid object, Java calls it "null", but you could have seen the concept thing called NULL, nullptr, NIL, nil, undefined, ..., in other programming languages.

The general sense of null (or whatever is its actual name in a specific language) is clear, but there are many subtleties on which there is no common consensus.

For instance, there are languages where null is considered as a synonym of the false boolean value, but this is not true for Java. And if you forget it, you could have some unpleasant surprise.

Let’s think to a simple method that just write a message if the passed parameter is a (primitive) boolean true.

public void test(boolean value) {
    if (value) {
        System.out.println("The value is set to true");
    }
}

Not an impressive piece of code, but at least it does what anyone would expect.

Here, the passed parameter is a primitive boolean variable, and Java primitive variable are not instance of classes but mere memory objects. They resolve to rough memory location, no pointers involved. So in a boolean variable we could store just a true or a false value.

Things are getting tougher if we apply a tiny "improvement" to our method:

public void badTest(Boolean value) {
    if (value) { // !!! fishing for troubles !!!
        System.out.println("The boolean is set to true");
    }
}

Now our class is accepting a Boolean (uppercase!) variable as parameter. That means a real object in the Object-Oriented sense of the word so, being here in the Java world, a pointer to an instance of a full-fledged class, or null.

The trouble is all in the last sentence tag: "or null". And null in Java is just an invalid reference, no implicit conversion to false, as it happens in other languages.

What happens if we call our method in this way?

bt.test(null);

The virtual machine would try to dereference the pointer to a Boolean, find out that it is actually impossible, and would pass back this valuable information to the caller in form of an exception. One would argue that any Java method should declare any exception that could be thrown in its body, and wonder why this is not happening here. Well, the fact is there is a family of Exceptions, with root in RuntimeException (an Exception extension) and all its derived classes, that are considered "normal", in the sense they could happen anywhere and so are not required to be declared. Null pointer dereferencing, division by zero, and other calamities like that, are in this category.

The end of the story is, if we really need a Boolean, we should ensure that it is correctly set before using it:

public void testA(Boolean value) {
    if(value == null) {
        System.out.println("null is not false nor true");
        return;
    }

    if (value) {
        System.out.println("The boolean is set to true");
    }
}

Or, be prepared to manage a null pointer exception:

public void test(Boolean value) {
    try {
        if (value) {
            System.out.println("The value is set to true");
        }
    } catch (NullPointerException npe) {
        System.out.println("null is not false nor true");
    }
}

As often happens there is no generically better approach. In this case, I reckon it would be better to use the first way - explicit check of the pointer - if we actually expect null as a valid input value. On the contrary, if the would have expected the Boolean to be correctly set, and a null it is a sign of something wrong happened before, it could make more sense the try-catch solution.

Go to the full post

Unable to access jarfile

I wrote this post while I was working with the Java implementation of Saxon, a collection of tools for processing XML documents, and I bumped in a misleading piece of information while reading Beginning XML (surprisingly, because it is a book that I'd warmly suggest you to read) about executable JARs and their relation with the system CLASSPATH variable.

They say that you should put the Saxon JAR in system CLASSPATH so that you can run it in any folder. But this is not true, if you do it, you get a disappointing error: "Unable to access jarfile".

This is because, as said in the Java documentation about the -jar option: "When you use this option, the JAR file is the source of all user classes, and other user class path settings are ignored."

So, you should disregard what written in Beginning XML, and specify the fully qualified named for the executable JAR, something like this:

java -jar \dev\saxon\saxon9he.jar p293.xml p293.xslt

Go to the full post

The Eclipse dot launch file

Any Java class class could have its own static public (and void) main method, and any of such class could run as a standalone application in Eclipse. It is quite easy, right click on the class in the Package Explore, choose the "Run As" menu item, and finally select "Java Application".

Eclipse creates under the hood a default ".launch", a Java application configuration file, that will be used for each next request to run that class. We could modify it, or even create a number of different custom launch file to run our Java application with specific setups from within Eclipse.

By default the launch files are stored in a hidden folder in the metadata branch under the workspace directory, something like:

workspace\.metadata\.plugins\org.eclipse.debug.core\.launches\

There you could see all the .launch files available to Eclipse in that workspace. Instead of digging in the file system, you can see them opening the Run (and Debug) Configuration window that shows a filtered view of all the .launch files, from here you can easily create, edit and run your configuration files.

You could also create a specific folder in your project, and there modify a copy of the original .launch file as you please.

The .launch file is an XML that could be edited directly, if you are confident with its structure, or by Eclipse. You could set basically everything you would usually set in a script that runs the Java application directly from the operating system (program and JVM arguments, for instance), and in case of debug execution you could also set a breakpoint in the main class (there is a "Stop in main" check box in the main tab for launch configuration).

I found handy having a few local .launch files to test how my Java application react on being called with different configuration setup.

Go to the full post

Excluding a file from build path

Sometimes it happens that we need to temporary exclude a file from a project current build. Let's see how to do it in three major IDE: Eclipse, IntelliJ, NetBeans.

Eclipse

To exclude an item from the build, right click on it in the package explorer, select the "Build Path" item, an then "Exclude" it.
It is quite simple to revert the exclusion. Select again "Build Path" for it, now we see that we have a new option available, "Include". Just click on it and the current item is again part of the build.

IntelliJ

Access the Settings menu for the project (File, Settings - Ctrl+Alt+S), in the Compiler section access Excludes and there add the file.

NetBeans

Right click on the project name in the Projects navigator, then click on "Properties", and here, in the "Sources" Category, click on the button "Includes/Excludes". By default, in the Includes you seen "**", and the Excludes input line is empty.

Go to the full post

Filter

Filters are Java components similar to servlets that are used to filter the connection between client and servlets.

To create a filter we implements the Filter interface, specifying what it should do in the doFilter() method.

In the DD we could declare the filter (if we don't use the annotations that are now available) and we map the filter with the resources we want they want to interact with.

Let's see an example where the filter simply log the user name (when available) for any request sent to a servlet named with the extension ".do".

The class implementation:

package ch13;

import java.io.IOException;

import javax.servlet.Filter;
import javax.servlet.FilterChain;
import javax.servlet.FilterConfig;
import javax.servlet.ServletException;
import javax.servlet.ServletRequest;
import javax.servlet.ServletResponse;
import javax.servlet.annotation.WebFilter;
import javax.servlet.annotation.WebInitParam;
import javax.servlet.http.HttpServletRequest;

@WebFilter( filterName = "BeerRequest",
description = "log the caller",
urlPatterns = { "/BeerReqFilter" })
public class BeerReqFilter implements Filter {
    private FilterConfig fc;

    public void init(FilterConfig fConfig) throws ServletException {
        this.fc = fConfig;
    }

    public void doFilter(ServletRequest request, ServletResponse response, FilterChain chain)
    throws IOException, ServletException {
        String name = ((HttpServletRequest)request).getRemoteUser();
        if(name != null) {
            fc.getServletContext().log("User: " + name + " is updating");
        }
        else {
            fc.getServletContext().log("Remote user name not available");
        }

        // pass the request along the filter chain
        chain.doFilter(request, response);
    }

    public void destroy() {
    }
}

The doFilter() accepts Servlet Request and Response as parameter, we normally have to downcast them to the appropriate Http subclass in the method body.

At the end of the job, we pass explicitely the control to the next filter (or servlet) in the chain.

If we need, we could specify init parameters for the filter using the initParams attribute. For example, if we want to use a special log file, we can set it in this way:

initParams = @WebInitParam(name="LogFileName", value="UserLog.txt")

In the DD we specify when the filter should be used, like this:

<filter-mapping>
<filter-name>BeerRequest</filter-name>
<url-pattern>*.do</url-pattern>
</filter-mapping>

Filters are discussed in chapter twelve of Head First Servlet and JSP.

Go to the full post

Cooperating Tags

Sometimes it is useful having tags meant to work together. For instance we could like to have a sort of Menu tag that refers to MenuItem tags, so that we can write in a JSP page:

<st:menu> 
    <st:menuItem value="Dogs" />
    <st:menuItem value="Cats" />
    <st:menuItem value="Mice" />
</st:menu>

We want establish a sort of communication among them, so that an internal tag could access methods of the containing tag, and even modify it.

We can do that using the getParent() method provided by the SimpleTag (or Tag, if you are working with Classic Tags) interface.

Let's create a couple of Simple Tags that would let us testing the JSP code we wrote above. Our menu tag would have a private list of string, and would make available to the menuItem tag a method to add a value to it.

We expect the inner tags to do their job, and we, from the menu doTag() we are going to show the list that, after invoking the JspBody should contain the values set by the internal tags:

package ch10;

import java.io.IOException;
import java.util.ArrayList;

import javax.servlet.jsp.JspException;
import javax.servlet.jsp.JspWriter;
import javax.servlet.jsp.tagext.SimpleTagSupport;

public class MenuTag extends SimpleTagSupport {
    private ArrayList<String> items = new ArrayList<String>();

    // package visibility: internal use only!
    void addMenuItem(String item) {
        items.add(item);
    }

    @Override
    public void doTag() throws JspException, IOException {
        JspWriter out = getJspContext().getOut();
        out.print("Menu tag< br />");

        if(getJspBody() != null)
            getJspBody().invoke(null);

        out.println("< br />");
        out.print("Items are: " + items + "< br />");
    }
}

To be this tag available to our JSP page, we declare it in our TLD:

<tag>
    <description>Menu Tag</description>
    <name>menu</name>
    <tag-class>ch10.MenuTag</tag-class>
    <body-content>scriptless</body-content>
</tag>

All the rest of the job is done by the internal node class that, in its doTag() method, check if the tag has a parent and if it is of the expected type. If so, it calls the method we have expressly created for this scope:

package ch10;

import java.io.IOException;
import javax.servlet.jsp.JspException;
import javax.servlet.jsp.JspWriter;
import javax.servlet.jsp.tagext.JspTag;
import javax.servlet.jsp.tagext.SimpleTagSupport;

public class MenuItemTag extends SimpleTagSupport {
    private String value;

    public void setValue(String value) {
        this.value = value;
    }

    @Override
    public void doTag() throws JspException, IOException {
        JspWriter out = getJspContext().getOut();
        out.print("Menu Item tag: " + value + "<br />");

        JspTag tag = getParent();
        if(tag != null && tag instanceof MenuTag)
            ((MenuTag)tag).addMenuItem(value);
        else if(tag == null)
            out.print("no parent for this tag<br />");
        else
            out.print("parent is not a MenuTag");
    }
}

We can test it leaving a MenuItem tag free, or putting it in an unexpected tag:

<st:menuItem value="Horses" />
<st:simple2><st:menuItem value="Hippo" /></st:simple2>

Just remember to put in the JSP page the required taglib directive:

<%@ taglib prefix="st" uri="simpleTags" %>

More on tag handlers in chapter ten of Head First Servlet and JSP. A fun and interesting book, indeed.

Go to the full post

DynamicAttributes in Simple Tag

We wrote a Simple Tag that generates an HTML select-option structure that works fine but it is very limited: we can't use attributes other than the ones specified in its declaration.

It would be a code nightmare to implement a full fledged solution for all the attributes that could be used in a HTML select, fortunately there is another chance: using dynamic attributes.

We modify the tag class that now will implement the DynamicAttributes interface, that defines a method, setDynamicAttribute(), that let us manage any other attribute passed to the tag. We store them in a private map, and use when we create the HTML select tag.

Here is the code for the modified class:

package ch10;

import java.io.IOException;
import java.util.HashMap;
import java.util.List;
import java.util.Map;

import javax.servlet.jsp.JspException;
import javax.servlet.jsp.JspWriter;
import javax.servlet.jsp.tagext.DynamicAttributes;
import javax.servlet.jsp.tagext.SimpleTagSupport;

public class SelectTagEx extends SimpleTagSupport
implements DynamicAttributes {
    private List<String> options;
    private String name;

    /** stores the dynamic attributes */
    private Map<String,Object> tagAttrs = new HashMap<String,Object>();

    public void setOptions(List<String> options) {
        this.options = options;
    }

    public void setName(String name) {
        this.name = name;
    }

    @Override
    public void setDynamicAttribute(String uri, String name, Object value) // 1
    throws JspException {
        tagAttrs.put(name, value);
    }

    @Override
    public void doTag() throws JspException, IOException {
        JspWriter out = getJspContext().getOut();

        // generate the HTML select open tag
        // 'name' is a mandatory attribute
        out.print("<select name=" + this.name + ' ');
        for(String attrName : tagAttrs.keySet()) { // 2
            String attrDefinition =
                String.format("%s='%s' ", attrName, tagAttrs.get(attrName));
            out.print(attrDefinition);
        }
        out.print('>');

        // generate the required HTML option tags
        for(String option : options) {
            out.print("<option value='" + option + "'>" + option + "</option>");
        }

        // generate the HTML select close tag
        out.print(" </select>");
    }
}

1. We use the setDynamicAttribute() method for storing the attribute name and value in the member map - there is no use here for the first (quite obscure) parameter.
2. We loop on all the elements in the member map, and put them as attributes in HTML select tag.

We have to change accordingly the tag declaration in the TLD file, specifying that it accepts dynamic attributes:

<tag>
    <name>select</name>
    <tag-class>ch10.SelectTagEx</tag-class>
    <body-content>empty</body-content>
    <description>Select-option tag</description>
    <attribute>
        <name>options</name>
        <type>java.util.List</type>
        <required>true</required>
        <rtexprvalue>true</rtexprvalue>
    </attribute>
    <attribute>
        <name>name</name>
        <required>true</required>
    </attribute>
    <dynamic-attributes>true</dynamic-attributes>
</tag>

Now we can put in our tag even attributes that are not explicitely declared in our Simple tag. The nuisance here is that there is no check on the attribute names, so we could enter in the list whatever we like, and our tag is going to accept it without complaining:

<st:select name='color' blabber='blah' options='${applicationScope.colors}' />

Simple tag handlers are discussed in chapter ten of Head First Servlet and JSP.

Go to the full post