A generic cache object

Instead of doing a whole lot of if-else over the supported constructor classes, you could use Reflection to accomplish the construction of objects.

cacheableElementClass.getDeclaredConstructor or getDeclaredConstructors to retrieve the constructor you want to invoke.

Constructor.newInstance(params) to create the constructor.

Sample code that might work:

try {
    // assuming the class only has one constructor that we can invoke
    Constructor<?> constructor = cacheableElementClass.getDeclaredConstructors[0];
    Object instance = constructor.newInstance(params);
    cacheMap.put(cacheableElementClass, instance);
} catch (... /*a whole lot of exceptions*/) {
    ...
}

If you want to be sure only a limited number of classes are supported, put the supported classes in a HashSet and check if the hashset contains the class you want to retrieve.

The throwing of the NullPointerException would be better of as an IllegalArgumentException, and don't forget to provide a helpful error message.

I find it a bit funny weird that if you call this:

SourceCode a = (SourceCode) Cache.getCacheableElement(SourceCode.class, "A");
SourceCode b = (SourceCode) Cache.getCacheableElement(SourceCode.class, "B");

The second call will return the a object, with "A" as the string value. This makes me wonder a bit about the general design and purpose of this code, it feels a bit strange.

This method could make use of generics to avoid having to typecast the result:

public static ICacheable getCacheableElement(Class cacheableElementClass, Object... params) {

Make that:

public static <T extends ICachable> T getCacheableElement(Class<T> cacheableElementClass, Object... params) {

Although I think the ICachable marker interface is useless, I'd recommend making it just:

public static <T> T getCacheableElement(Class<T> cacheableElementClass, Object... params) {

I've answered the question before it's reached it final state, so I'm adding a review on this part:

    if (cacheableElementClass.equals(SourceCode.class)) {
        cacheMap.put(cacheableElementClass, new SourceCode((String) params[0]));
    } else if (cacheableElementClass.equals(SymbolTable.class)) {
        cacheMap.put(cacheableElementClass, new SymbolTable());
    } else {
        // Error!
        throw new NullPointerException();
    }

It feels hacky and the problem seems to be the very existence of the universal all-classes-managing Cache and the existence of ICacheable. With not concentrating the code around this, you could have something like this

public SourceCode getSourceCode(String param0) {
    SourceCode result = sourceCodeCache.get(param0);
    if (result == null) {
        result = new SourceCode(param0);
        sourceCodeCache.put(param0, result);
    }
    return result;
}

Above, I'm assuming that you need multiple elements per cacheableElementClass. Assuming I'm right, you get more type safety by

• returning SourceCode rather than ICacheable
• passing String rather than Object...

Assuming you really need just one element per class, then you should consider pre-creating all of them and use a ClassToInstanceMap to retrieve them in a type-safe manner.

If you can't pre-create one stupid instance per class, then reconsider the whole design. It may be right, but probably is not.

An afterthought

Maybe you need something completely different, namely a couple of singletons. Probably, there should be exactly one SourceCode and exactly one SymbolTable in your whole code. This is where the singleton (anti-)pattern would help. A better alternative is to use DI, i.e., create all needed stuff somewhere in main and pass it to everyone needing it. It may get verbose, but it's pretty simple and perfectly testable. Once it gets complicated, use Guice to manage your dependencies.

Since your cache will be used application-wide, I think it should be thread-safe because otherwise the state of your cache might change halfway through an operation. To do this, add the synchronized keyword to your method signature. (I've never done thread-safety in java, only c#, so I might be a little off on the best practices about that in java.)

Also, the method named getCacheableElement might add an object into the cache, but it is impossible to know this without first checking the source code. I don't think a single method to do add and get is a good idea. Why not split in 2 different methods?

This cache implementation is not generic. Imagine I want to use your cache in my application, I wouldn't be able to do it since my classes wouldn't be part of your if,else if,else.

Throwing NullPointerException isn't a good idea. You might want to create a custom exception like KeyNotFoundException.

A small thing, in addIfNotExists you check if it's a few different types and if it's not you do throw new NullPointerException();.

if (cacheableElementClass.equals(SourceCode.class)) {
    cacheMap.put(cacheableElementClass, new SourceCode((String) params[0]));
} else if (cacheableElementClass.equals(SymbolTable.class)) {
    cacheMap.put(cacheableElementClass, new SymbolTable());
} else {
    // Error!
    throw new NullPointerException();
}

I don't like the use of NullPointerException here. If cacheableElementClass is null then it's fine (but I still don't like it). It seems better to throw a InvalidArgumentException. In addition, if it actually was null it would throw a "real" NullPointerException at the first if statement.

I recommend this, but it's ugly. I'd like it better if the InvalidArgumentException throwing was at the top, but it's a trivial change you can figure on your own (It makes sense for all preconditions to be at the top).

if (cacheableElementClass == null) {
    // Error!
    throw new NullPointerException();
}

if (cacheableElementClass.equals(SourceCode.class)) {
    cacheMap.put(cacheableElementClass, new SourceCode((String) params[0]));
} else if (cacheableElementClass.equals(SymbolTable.class)) {
    cacheMap.put(cacheableElementClass, new SymbolTable());
} else {
    // Error!
    throw new InvalidArgumentException();
}

The only reason I even include the manual throwing of NullPointerException is because I assume you do more stuff in the // Error! part, if you don't, remove it because it will do that on its own without you writing it in.

If you're using Preconditions library you can do this:

Preconditions.checkNotNull(cacheableElementClass);
// Preconditions.checkArgument(cacheableElementClass != null);
Preconditions.checkArgument(cacheableElementClass.equals(SourceCode.class) || cacheableElementClass.equals(SymbolTable.class));

if (cacheableElementClass.equals(SourceCode.class)) {
    cacheMap.put(cacheableElementClass, new SourceCode((String) params[0]));
} else if (cacheableElementClass.equals(SymbolTable.class)) {
    cacheMap.put(cacheableElementClass, new SymbolTable());
}

The commented out line is basically the same as the checkNotNull but it throws InvalidArgumentException which to me is just more informative in this case than NullPointerException, but it's up to you which you prefer.