Ruby on Rails guides

Rails i18n and Google Group

Images are a great portion of a website, they help to make it fancy and good looking. They also have great potential for optimization, to speed up your website and minimize you traffic. There are several ways to improve image size and , you don’t have to know them at all, just use smush.it! Smush.it is a tool from Yahoo performance team members that let you optimize your images on the fly. Normally I would now explain how to use the tool and so forth, but not smush.it. It is as simple as it can be. Just go to the website and get a free overhaul for your images. Oh and btw plans are to make the tool open source Love it

For those who are interested know, just visit www.timewhale.com and register for the launch announcement. Your email will be used to send you one email for the launch announcement and after that it is deleted, so no obligations and no spamming.

Mac ships with Java 1.5 and 1.6 is available too. The problem is that only binaries are installed and as a serious developer you need also sources and documentation. So to get them, you have to join the Apple Developer Connection (the free version does it) and download the  Java for Mac OS X 10.5 Update 2 Developer Documentation (or probably a higher version in the future). The download is around 130 MB and includes sources/documentation for Java 1.5 and 1.6. Probably you have to set the src.jar and docs.jar manually to existing JVMs or just delete and add the existing ones.

Eclipse: Preferences - Java - Installed JREs - Select Installed JRE and click Edit

NetBeans: Tools - Java Platform - Add or select the right Tab

In short this error means that the jvm cannot get more memory from the operating system. For us this meant there has to be native memory leak in the jvm or in the OS side. Since the library is for communication and uses heavily sockets, our first guess was a socket problem. Investigating the code of the library (gladly we have the source files) brought no results. During my research (what a fancy word for googling) I stumbled across this forum thread. It describes a native memory leak that occurs when a ClassCastException is thrown! Further, the bug is still not fixed. I remembered that there are a lot of casts in the third party library, so I started testing how fast the memory grows. The following code pushes the memory usage to 340 MB:

package com.hemju;

/**
* Example of the {@link ClassCastException} memory leak.
*
* @author Helmut Juskewycz, hjuskewycz - at - hemju.com
*/
public class CEMemoryLeak {

public static void main(String argv[]) throws Exception {
Object sObject = new String("Hello Leak");
Integer intObject = new Integer("5");

for (int i = 0; i < 5000000; i++) {
try {
intObject = (Integer) sObject;
} catch (ClassCastException ex) {
}
}
Thread.sleep(60000);
}
}

Our application crashed with about 600-800 MB memory, hence, over 10 000 000 Class Cast Exceptions have to be thrown and caught! A lot of exceptions, nevertheless it was possible because we tested the application under heavy load. Phaser, äähh debugger set on thrown Exceptions with a hitcount of 1000 and start the engines. Under a minute Eclipse’s excellent debugger lead us to a code fragement which does basically this:

...

Date date = null;

try {

date = (Date)obj;

} catch(Exception e) {}

if(date==null) new Date();

...

This fragement is bad in several ways, so never ever do that! Never catch silently an exception, never catch more than needed, and never ever use an exception to control the code flow! Until I discovered this fragment I had a good impression of the library’s code quality. So why would someone do that? I believe there has to be reason for doing it. Is it faster than a simple instanceof? If you know, please drop a comment.

My conclusion: Granted, throwing so much ClassCastExceptions is rare. That is good so. In my opinion casting should be avoided when possible, it often comes with a not-so-good design. When you can’t avoid it, handle it correctly! And be aware that a ClassCastException can lead to a native Memory Leak in java up to version 6, it should be fixed in Java 7.

Last time we switched from a static approach to an instance based one and introduced a register-method to allow adding Singletons from everywhere. There are several issues with this approach:

• doesn’t support lazy initialization, so far only eager initialization was done
• sometimes not all necessary information is available at register time to actually create the Singleton instance
• maybe you want to track, creation, requesting, and so forth of the Singleton.

Sounds complicated and scary? It isn’t, delegation is our friend again. Another way would be the observer (listener) pattern to address the above mentioned issues, however, delegation is more elegant and appropriate for this task.

Actually, the solution is as simple as it could be. We outsource (outsourcing in IT is a big thing!) the creation of Singletons to our new SingletonCreator interface. A SingletonCreator creates, like the name suggests, Singletons.

public interface SingletonCreator<T> {

T getInstance();

}

The neat thing is that it is up to the implementor how and when everything is done. E.g. eager/lazy initialization is defined by the implementation. But you don’t have to stop here. What about a time based Singleton? Only available through 8:00 to 17:00 from Monday to Friday (the unions are killing us)? Not a problem. You can also track Singleton instance requests or persist (serialize) them. Everything possible with SingletonCreator. So let us make the necessary changes to S and SingletonHashMap:

S.java

public abstract <T><T, E extends T> void register(Class<T> clazz, SingletonCreator<E> creator);

SingletonHashMap.java

private final HashMap<Class<?>, SingletonCreator<?>> singletons =
new HashMap<Class<?>, SingletonCreator<?>>();

HashMapSingleton() {
super();
// register as Singleton
register(S.class, new SingletonCreator<S>() {
@Override
public S getInstance() {
return HashMapSingleton.this;
}
});
}

@SuppressWarnings("unchecked")
// checked via register!
@Override
<t> T _get(Class<T> clazz) {
// TODO check for null values
return (T) singletons.get(clazz).getInstance();
}

@Override
public <T><T , E extends T> void register(Class<T> clazz,
SingletonCreator<E> creator) {
// TODO check for null values
singletons.put(clazz, creator);
}

SingletonHashMap already reveals how the new solution works, but isn’t the best example with all that clumpy syntax. Here is a better one, the Main class which registers our System.out and System.err printer:

package com.hemju;

public class Main {

public static void main(String[] args) {
// S.get(S.class).register(MyPrinter.class, new SerrPrinterCreator());
S.get(S.class).register(MyPrinter.class, new SoutPrinterCreator());
MyPrinter printer = S.get(MyPrinter.class);
printer.print("Hallo aus Linz");
}

private static class SerrPrinterCreator implements SingletonCreator<MyPrinter> {
// eager init
private final MyPrinter printer = new MySerrPrinter();

@Override
public MyPrinter getInstance() {
return printer;
}
}

private static class SoutPrinterCreator implements SingletonCreator<MyPrinter> {

private MyPrinter printer;

@Override
public MyPrinter getInstance() {
// lazy init
if (printer == null) {
printer = new MySoutPrinter();
}
return printer;
}
}
}

I am pretty satisfied with the solution by now.  So what do you think about my Singleton solution? I attached the source code, so you can easily investigate the code.
One last word of cautions. Like most things in life nothing comes for free. Our new introduced flexibility holds certain pitfalls, or as we all know: With great power comes great responsibility. You don’t know what a SingletonCreator returns (null, a new instance every time, …). I will think about this possible problem, but until that I guess you have to trust your fellow programmers and of course yourself.

First, I want to get rid of the static context. Static is very simple but also restrictive and we want and need flexibility later on. So instead of using static variables the get-method should delegate to the real implementation of the Singleton. How does this change our code?

public abstract class S {

private static final S SINGLETON; //???

@SuppressWarnings("unchecked")
public static <T> T get(Class<T> clazz) {
return SINGLETON._get(clazz);
}

S() {
// make Singleton accessible only through static references
}

abstract <T> T _get(Class<T> clazz);

}

Instead of static, the Singleton class (I renamed it to just “S” because of shortness) is now abstract. It is still the entry point for getting an instance, but now delegates it to an implementation of S. So it is possible to use different types of S. For now this gives us no real advantage, but in the next parts of the tutorial you will see how this helps us. Please also note the use of Java’s default visibility. When S has its own package, rest of the application isn’t aware of the _get-method. To use S, we need an implementation of it:

public class HashMapSingleton extends S {

private final HashMap<Class<?>, Object> singletons =
new HashMap<Class<?>, Object>();

HashMapSingleton() {
super();
singletons.put(MyPrinter.class, new MySoutPrinter());
}

@Override
<T> T _get(Class<T> clazz) {
// TODO check for null values
return (T) singletons.get(clazz);
}

}

S now could just create an instance of HashMapSingleton and then delegate the requests to it. But we want a more flexible solution. I personally see no need for supporting runtime exchange, (too flexible, although it is possible) and since another goal is simplicity, the easiest way is deciding at startup which Singleton implementation to use. I am not a mind reader, but I guess the chance that you think ‘Here comes the configuration file!’ is pretty big. Not so fast, simple also means no configuration files. Therefore, we are using plain, oldschool Java System properties to determine which implementation to use. Adding the following lines should do the trick.

static {
String singletonClassName = System.getProperty("com.hemju.S");
S singleton = null;
try {
singleton = (S) Class.forName(singletonClassName).newInstance();
} catch (Exception e) {
e.printStackTrace();
}
SINGLETON = singleton;
}

When we start our program with the VM argument -Dcom.hemju.S=com.hemju.HashMapSingleton, everything should just work fine. One more thing bothers me. Can you recall why we did introduce S in the first place? Exactly, because a class should do only serve one purpose. HashMapSingleton does managing and creating the Singletons and latter is clearly not its responsibility. Therefore, we introduce another method in S that allows registering Singleton instances.

S

public abstract <T><T, E extends T> void register(Class<T> clazz, E impl);

HashMapSingleton

@Override
public <T><T, E extends T> void register(Class<T> clazz, E impl) {
// TODO check for null values
singletons.put(clazz, impl);
}

Now it is possible for other classes to register Singletons. Wait, no static register? We don’t need one, we just register HashMapSingleton as a Singleton for S and S.get(S.class) gives us exactly what we want.

I think this solution is already better than the previous one, but there are still issues to be addressed which we will do in the next part.

Singletons are a great example. They are simple to understand and to use. Like I mentioned, DI frameworks are often used to provide a “better” way to create Singletons, sometimes as their main purpose. I will present a simple , yet powerful enough, solution creating and instrumenting Singletons using a plain HashMap with no dependencies and configuration files.Why are Singleton considered bad? We all use them, we all need them. I think the problem is not using Singletons, it is to create them. We all have seen code like this:

public static final Application APPLICATION = new ApplicationImpl();

This code creates a Singleton of the interface Application. Through the public static modifier it is available for all other classes. Our problem solved! Not yet, where should we place this code? We could make Application an abstract class and place the static variable in it. But I don’t like this solution much. Why? Because a class should only do one thing. Application already has a purpose (some application related things), but creating a Singleton is clearly not Application’s job. Hence, we are creating a Singleton class that creates a Singleton for us. Instead of doing this with a public static variable we will provide a generic static method for it. Something like Singleton.get(???). Our get method needs a parameter to identify which class should be returned. We could create an enum Key, but then we also need to create a Key instance for every interface we want to register. A key already exists, the class of the interface. What about calling Singleton.get(Application.class)? That will do it. A HashMap then can hold the Singletons and get() returns the corresponding instance to the interface. Further, generics helps us to avoid casting.

Singleton.java

package com.hemju;
import java.util.HashMap;

public class Singleton {

private static final HashMap<Class<?>, Object> SINGLETONS =
new HashMap<Class<?>, Object>();

static {
SINGLETONS.put(Application.class, new ApplicationImpl());
}

/**
* Returns a singleton which implements the given interface.
*
* @param
*          the interface which is implemented
* @param clazz
*          the class object of the interface
* @return a singleton instance of an implementing class or
*         <code>null</code> when no implementation was found
*/
@SuppressWarnings("unchecked")
public static  T get(Class clazz) {
return (T) SINGLETONS.get(clazz);
}

private Singleton() {
// make Singleton accessible only through static references
}
}

Done! We already can use our simple Singleton solution. Have a look at the example at the end of this text. I am still not 100% satisfied with the solution, but we are going in the right direction.

Open issues are:

• not really flexible
• no access control
• no exception management (casting null values)
• doesn’t work with Unit tests

I will address this issues in the next part of this series. If you think I missed any issues, just drop a comment and let me know.

Example:

package com.hemju;

public interface MyPrinter {
void print(String s);
}

package com.hemju;

public class MySoutPrinter implements MyPrinter {

@Override
public void print(String s) {
System.out.println(s);
}

}

package com.hemju;

public class MySerrPrinter implements MyPrinter {

@Override
public void print(String s) {
System.err.println(s);
}

}

package com.hemju;

public class Main {

public static void main(String[] args) {
// don' forget to add
// SINGLETONS.put(MyPrinter.class, new MySoutPrinter());
// in the Singleton class
MyPrinter printer = Singleton.get(MyPrinter.class);
printer.print("Hallo aus Linz");
}

}

Here a picture from the new look (screenshot is borrowed from Japser ) Thank’s Jasper and Nimbus team