Reflection and Singletons

*** Posted on All rights reserved ***

Java reflection is one of those tools that you may go for years without using, and never miss it. Until the day comes that you have to invoke methods without knowing what they are in advance. When that happens, reflection will be the thing that would prevent you from jumping off the nearest cliff. IF you do it right.

Invoking a method by reflection is fairly straight forward: You get a Class object that describes the class of the method that you are trying to use, get the method you want, and create a method object that represents that method. I wont go into the details or code for this, but you can find a fairly comprehensive guide here.

The tricky part starts when you attempt to invoke the method. The signature for invoking a method requires an object that the method is invoked on, and the list of parameters. In other words, if you are trying to invoke method myMethod() from Class MyClass, the reflection API wants to know which object of MyClass do you want to call that method. The API even goes a step further and lets you specify that a new object should be created for this by invoking the Class.newInstance() method which calls the default no-args constructor of the class. So far so good.

But what happens if the class you are trying to call is a singleton? (I know I said that Java doesn’t have real singletons, but what it does have behaves enough like a singleton to cause this problem) Remember that in a singleton, there are no public constructors, and the only way to get an object of the class is by calling getInstance(). Unfortunately, if you are using reflection you can run into a situation where the object you are invoking at any particular iteration may or may not be a singleton and you wont know in advance, and calling newInstance() on a singleton will definitely not work as advertised. So what do you do?

What you can try to do is something like this:

Object obj = null;
Class<?> cls = Class.forName(className);
Method methodIWantToInvoke = cls.getMethod(methodName, Params);

     Method getinst = cls.getMethod("getInstance",null);
     obj = getinst.invoke(null, null);
     }catch(NoSuchMethodException n){
     try {
         obj = cls.newInstance();
     } catch (InstantiationException e) {
Object result = methodIWantToInvoke.invoke(obj, params);

What you are doing here is using reflection to get an object so that you can use reflection to invoke a method. 🙂

If the Class object cls describes a class that is a singleton, then the request to getMethod(getInstance(), null) will give ou back a Method object that you can invoke to get the instance of the singleton you need. If it isn’t a singleton, it will throw a MethodNotFoundException, in which case you know you can use plain old newInstance you invoke the constructor.  Either way, but the end of this, you can an Object that you can then pass to the method you originally wanted to invoke in order to invoke it.

Note that the order of actions here is arbitrary: You can just as easily call newInstance first and then (upon getting an IllegalAccessException) try getInstance(). You can also combine this with a static factory method to allow calling of constructors other than the no-args, which adds to your flexibility.

Using reflection is realy not as complicated as it might seem, but there are (at least) two things you must by mindful of:

1. Reflection is slow and heavy. It adds a lot of overhead to your code and should be used very judiciously (for a bit of insight to the overhead, checkout Dennis Sosnoski’s Java programming dynamics article. It’s a little dated, and reflection HAS become more efficient, but it’s still no where near directly coding)

2. One of the more common uses of reflection is with serialization, to examine and use de-serialized objects. This is exactly where Java Singletons fails. If you have an Object that was serialized and then deserialized in different JVMs, even though you can successfully call its getInstance() method with the code above, you are still not getting the same object.

Good luck, and happy coding,



Java Singletons don’t exist.

*** Posted on All rights reserved ***

When I first started in my current project I set down to a code review with the lead programmer to see “my” project. At some point during the review, the man pointed to a certain class that was being used as part of the startup sequence for the application and said “this should be reimplemented as a singelton”. Up until then I was following him closely, but that statement took me by surprise, because as far as I knew, singletons don’t exist in Java.

To understand why, we have to look at the definition of a Singelton:

A singleton is a pattern that permits exactly one object that is needed to coordinate actions across the system.

In other words, whereever I am, if I try to use a class that is defined as a singleton, I would always, always, get the SAME object.  Usually, a native implementation of a Singleton looks something like this:

public final class MySingleton{

private MySingelton me=null;

private MySingleton(){
   ...instantiation code here...

public Mysingelton getInstance(){
  if (null==me) me = new MySingelton();
  return me;


As you can see, MySingleton has no public contractors. It can’t be directly instantiated or inherited. You can only get a MySingleton Object by calling getInstance(), which always returns the same object. This makes the singleton very handy for coordinating actions across a system. System states, for example, can be saved as singletons, as can factories, shared queues (a synchronized singleton), thread states, etc. Everywhere in the system that you can the singleton’s name, you’re guarantied to have the exact same object returned to you.

So why are there no Java singletons? Clearly the code above is written in Java and would run in Java, and would function as expected in a Java program. The reason this is not a singleton is the last part of the singleton definition “across the system”.

Consider: In C++, I can use code very much like the one above to tell me if a program has been launched. On the first time that the program runs, it asks for the singleton object, gets it (after it has been allocated by the system) and modifies it to indicate that it had been launched. If the program is then launched again, the second instance of the program would request and get the SAME singleton, see that the “running” state has already been set, and exit. The singleton is used across the system in coordinate states.

In Java, on the other hand, every program instance would run in its own instance of the JVM. This means that when the second instance of the program is launched, it would NOT get the same object as the first instance, but rather it would get the instance that has just been instantiated in its own JVM. The code above can coordinate across the same JVM, but it fails to coordinate across the system. Therefore, it does not qualify as a true singleton.

This may seem like splitting hairs, but it’s a very important thing to know. The guy I set with in the code review was pointing at a class who’s job was to make sure only one instance of the application would ever launch. We work on a project that does network measurements and topographies. It sends out packets with different addresses and TTLs and uses the returns to map the Internet. If we have two instances of the application running at the same time, we may not know which packet was sent by which instance, and our results would be compromised. Furthermore: We allow our users to run the application as a service, or as a standalone GUI based program. If we don’t have mutual exclusion, we can run into a situation where a user had installed the service AND the GUI, and starts both, thinking that the GUI just reflects the service. This could very easily lead to corruption in our data, and problems in the whole research.  All because Java singletons aren’t really singletons.

The good news is that in 95% of the cases, the code above would work quite nicely as a singleton. So long as you are staying within the JVM, it’s fine. For the last 5%, there are workarounds that can make mutual exclusion possible in Java. I will post about that some other time, though.

Good Coding,


Just because it’s not an error doesn’t mean it’s right

*** This post belongs to, all rights reserved ***

I was working on a PHP script the other day, and the damn bastard just wouldn’t work. I mean, the code was fine, no errors, no problems in compilation or anything like that. It ran perfectly, except that it didn’t do what I wanted. Worse than that: it was inconsistent about it, sometimes it was fine, and sometimes the results just didn’t make sense. It all depended on the input it got.

After much head scratching and dark thoughts about throwing my computer out the window and becoming a Shepperd, I found the problem: in one of the functions that was suppose to cleanse the input had a call to strripos when it really needed a call to strrpos, happens.

The thing is that this really shouldn’t happen, and if it does it shouldn’t take so long to diagnose. What a function does should be immediately and unambiguously clear by looking at its name. when you have strripos and strrpos, strtr and strstr, and stripslashes and stripcslashes, that makes it very hard to understand the code. I consider this readability problem to be one of the most fundamental flaws of PHP as a language. Luckily, this was a fairly simple and easily tested script. But consider having to read through 10,000 lines of code just to figure this out. (Yes, I know, you wouldn’t actually read all the code, you’d debug and trace the problem. But the point still stands that the code is harder to read)

Java, thankfully, does not do this. The naming conventions in Java describe ways to avoid this kind of scenario by outlining method names like “toString” “getVariable” and “isValid” which are self-explanatory. But this does not mean that Java is innocent of sin. Consider this scenario: You have a class MyClass and you need to write two constructors for it. Each constructor gets a JFrame and a String, and based on which ones it gets, it will show different information in the frame.

Now, since these are constructors, you can’t give them different names. And since they both have the same number and types of variables, you can’t distinguish them that way. So what you end up doing is distinguishing between them based on the variable order: One constructor is going to be MyClass (String, JFrame) and the other will be MyClass(JFrame, String). All perfectly legal in Java and aren’t you smart.

But now you face the same problem that I faced earlier in PHP: your method calls are non-descriptive and you can’t, based on the method name and signature, tell which constructor your actually using. Sure, you remember which is which now, but what about in six months when you have to get back to it and you’ve forgotten it all, or worse, someone has to maintain your code?

There are several solutions to avoid this kind of problem. My personal favorite is the one suggested by Joshua Bloch in his book “Effective Java” where he recommends using static factory methods instead of constructors.  Consider the two constructors above: If you made them private and instead added static methods with distinct names static getNewMyClassA and static getNewMyClassB you would eliminate the confusion and make it unambiguously clear as to which method does what. Furthermore, you’d gain much greater control over your Object creation, allowing your class to offer objects out of a pool, for example, rather than creating a new object every time. You also have a polymorphic advantage: a static method can return an object of any subclass of its return type, which can be handy.

Debugging and maintaining code are some of the most challenging tasks that a programmer can face. Sometimes, making the code more readable can be the only thing between you and a life as a walking sheepdog. 🙂


A rose by any other name… Object serilization and the Java JVM

***This post belongs to All rights reserved ***

Consider the two classes here. They’re identical in every meaningful way. The one on top belongs to a server application of some sort, whereas the one on the bottom belongs to the client to the same server. Both classes have the exact same members, methods, and constructors. Both have the same name. And both implement the serializable interface, which designates them as being able to be written out and read as complete objects. If you are not familiar with the wonderful world of Java serialization, look here

Now lets say that I have a server program that looks something like this:

ServerSocket sSocket = new ServerSocket(12345);
Socket iSocket = sSocket.accept();
ObjetOutputStream OOS = new ObjectOutputStream(iSocket.getOutputStream());
OOS.writeObject(new MyClass(10));
ObjectInputStream OIS = new ObjectInputStream(iSocket.getInputStream()):
MyClass aMyClass = (MyClass)OIS.readObject();

We also have a client class that looks like this:

Socket cSocket = new Socket(IP_CONSTANT, 12345);
ObjectInputStream cOIS = new ObjectInputStream(cSocket.getInputStream());
MyClass cMyClass = (MyClass) cOIS.readObject();
ObjectOutputStream cOOS = new ObjectOutputStream(cSocket.getOutputStream());
cOOS.writeObject(new MyClass(10+cMyClass.getT());

If you’re not sure about the flow here, it goes like this:

Server runs, and blocks on accept();

client runs, connects to server, and blocks on readObject

server unblocks at accept, transmits a MyClass object on the stream and blocks on readObject()

client unblocks on read, gets the Object object, casts it to a MyClass object (since readObject() returns an object of type Object), manipulates it, and sends it back to the server.

server unblocks on read, gets the Object object, casts it to a MyClass object, gets the value from it and prints it out

Now here’s a trick question: What the final output of the server program?

Well as it turns out the output is an exception that looks something like this:

Furthermore, the client program will throw it’s own exception:

java.lang.ClassNotFoundException: com.mycomp.myprod.server.common.MyClass
at Method)
at java.lang.ClassLoader.loadClass(
at sun.misc.Launcher$AppClassLoader.loadClass(
at java.lang.ClassLoader.loadClass(
at java.lang.ClassLoader.loadClassInternal(
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(

What happened?  We serialized an object, sent it over a stream, deserialized it, cast it back and then did it again the other way. This is exactly what serialization is designed for. Yet it seems to fail even at this humble level.

The critical error is the ClassNotFound exception for MyClass.  The JVM can’t find an object that fits this discription, so it throws an error. This causes the receiver to not run at all; which in turn causes the sender to shutdown with an End Of File. Although both the server and the client have a copy of MyClass, and as we’ve shown in the beginning of the post, they are identical, the JVM isn’t happy. It doesn’t just want an identical class, it wants the same class. client.MyClass and server.MyClass may be identical, but they’re not the same.

If you think about it, this makes a lot of sense. The JVM has no way of knowing that client.MyClass and server.MyClass are the same. As far as it knows there are also a foo.MyClass, a bar.MyClass, and an iphonesarebad.MyClass, each with different purposes and construction. But when the JVM reads the object head from the stream, it is told to look for a server.MyClass, and that’s exactly what it does. No class, no dice.

Note that this is not a ClasssCastFailed exception. The JVM never gets that far, and never gets to try and cast the object into the local form of MyClass. It simply looks for a class on the output side of the stream that matches the class that was present on the input side of the stream which means looking in the the directory specified by the class name (/com/mycomp/myprod/server/common) for the file specifed by the class name (

How do you get around this? Simple: Make sure that in both client and server the class you are serializing resides in the same relative path. This way, when the JVM looks in the path to find the class definition, it actually finds it, and everyone is happy. If you are really slick, you can put all of the code that’s common between the client and the server in its own JAR, but’s that’s a discussion for a different day.


De-Coupling MVC with Facade classes

Please note: The original url for this post is:
If you are reading this on any other web site, this content is stolen.

One of the best and worse things about Java is the easy way it allows you to create GUI elements and their associated commands together, which makes for very simple way to develop user interfaces.  This is one of the best features because it allows developers to concentrate on developing program logic, and simplifies interacting with the user to a level attainable even by beginners. It is one of the worse because this integration can lead to a very tightly coupled View and Control. Two of the three major part of the Model View Control (MVC) design pattern. MVC calls for each part to be separate and independent, so as to allow better code re-usability, easier maintenance, and better task grouping. This is certainly possible in Java, but requires more work then just building the control logic right into the GUI classes, and so developers don’t always bother to make the separation.

My current project, for instance, uses exactly this kind of tight coupling, which I’m trying to undo. I am looking to separate the view and the controller into independent code, and actually into different programs. The controller and model code requires administrative privileges to run and need to run all the time, while the GUI code requires just regular user privileges and only when the user wants it. So I’m separating them into two separate programs which will communicate over a shared channel.

The problem, as I mention, is that my GUI and the actions that it creates are coupled very tightly with the controller code itself. There is no point were controller threads are registered on GUI components and get notify()ed of state changes (yes, a Java method as a verb. Live with it). Rather ActionListeners directly invoke methods in the controller classes to make things happen in the program. It works, but it’s a bit messy, and can be a real problem considering that in the new paradigm, all commands and feedback are going to travel over one point of contact (the Channel). There are twenty-some methods being invoked from three classes that are part of the program cotroller. All of thoes need to be brought under one roof.  I could rewrite every one of them to call my ChannelCommunicator class instead, and ask it to transmit the command to the controller, but this is both tedious and potentially dangarous since I don’t know what else in the code is dependet on those methods being invoked in this certain way.

Facade classes to the recue! A facade class is a class which presents a simplified view of a subsystem and makes it easier to use. In my particular case, this means that I can create a facade for each of the three classes mentioned above. The facade function as an abstraction layer which implements the methods that my GUI classes expect to finds on on side, and passes calls to the ChannelCommunicator in a unified way on the other side. The GUI is happy because nothing has changes (except for the class name), the ChannelCommunicator is happy because it gets one type of call and doesn’t need to deal with special cases, and I’m happy because I don’t have to re-write every method that’s involved! Fantastic!

The thing to remember about this paradigm is that your facades come in pairs, and thus there is a certain amount of duplication involved. Why pairs? bacause I have to put a facade for the controller between the GUI and the ChannelCommunicator and, on the other side, I have to put a facade for the GUI between the ChannelCommunicator and the controller. The nice part about it is that these classes are really nothing more than parsers which translate the specific format of each command into a standard format the communicator can understand, and parse it back on the other side, so the logic involved is not very complicated. Still, this is a stopgap solution to allow MVC decoupling without having to redesign major parts of the code. In a perfect world you’d be better off re-writing the methods. But then, in a perfect world you wouldn’t have this problem to begin with. 🙂


P.S. To learn more about design patterned I would highly recommand Bruce Eckel‘s book Thinking in Patterns, which is available to download for free.

Java Thread Priority – The Awful Truth!

Ok, ok, I admit I might have been watching a little too much E!® channel lately, and the threading system in Java isn’t that awful. But if you will, let’s try a little exercise:

First of all, an easy question: What’s the default priority for a newly created Java thread? (Hint: it’s listed as NORM_PRIORITY here.)

For anyone who answered “5” (with or without looking) congratulations! You’re right. There are 10  internal levels of priority in Java, and 5 is considered the “normal” priority, and the default for new threads.

Now lets do a little mind experiment: Lets say you write a program that does some calculation and displays the result to a swing GUI. Your program gets its input automatically, and it can start calculating as soon as it starts up, so the first thing you do in your main(args[]) is to spawn a calculation thread to do the work. It gets a priority of 5, as we said. Great so far.

Now, on your GUI you are beginning to get results from your calculations. But they’re not coming as quickly as you need them. It’s just that the calculations are really I/O bound, and it takes a long time to get them, so that your calculation thread (and your CPU) spend a lot of time waiting idle. You decide to help the situation a long a bit by pressing the button on the GUI that would spawn a second calculation thread. Same code, same class, same parameters.

OK. Pop quiz, hot shot: What’s the priority of the second calculation thread?

If you answered 5 again, you’d be wrong. The new thread has a priority of 6. Don’t believe me? Try it.

What’s happened? How did identical threads end up with different priorities?

The answer is that, while it is true that the “default” priority for a Java thread is 5, that’s just about meaningless because A Java thread inherits the priority of its parent thread. In this particular case, the thread that created the second thread was the EventDispatcher thread, which is responsible for handling GUI tasks. Since it’s generally desired that a GUI be responsive no matter what the application is doing, this thread was given a default priority that is a little higher then the rest: 6. This is all fine and well, except that every thread that is created via this thread also has that priority. This can lead to a situation where practically all threads are running in this “elevated” priority, which not only defeats the purpose of of setting that thread higher, but can actually cause execution problems.

I’ll give an example: I’ve had a task recently to move our program’s system tray icon implementation from a 3rd party jar to the newfangled Java 6 built-in implementation. In my coded I spawned a thread to deal with the action events that come from the system tray, and like a good boy (who’s aware of how Java thread priority actually works) I manually set the priority of the thread to Thread.NORM_PRIORITY, where it should be. The results were incredible: from an average shut-down of 1-3 seconds, the program began taking up to several MINUTES to shutdown. Taking out the setPriority line fixed the problem, but exposed a different one: The previous programmers who had worked on this program didn’t realize that the priority is inherited, and let it as is. This meant that practically EVERY thread was running with priority 6 EXCEPT mine. The program took so long to shutdown because the thread that was suppose to tell all the other ends to stop couldn’t get a word in edgewise! Oooops. (not a good word to hear about your code)

The actual truth is not quite that terrible as I make it sound. Most preemptive, time-slicing Operating systems (Like Windows® and Linux) wont let a thread completely starve, and will temporarily assign a higher priority to a low thread that hasn’t ran in a while. As I understand it, there was also some re-shuffling in the way Java 6 maps internal priorities to Windows priorities that makes priority 5 and 6 virtually identical (Although I would point out that the example above was on a Java 6 JVM running on Vista®) But still, this is something of which anyone who write GUI code must be aware.


Java Strings are immutable, dangit!

For the past three days, and probably for the next three weeks, I am cleaning code. This is usually a good thing, since code is like your room:  It collects random bits and pieces that seemed important at the time, but now you look at and go “what does this thingy do? ”  and “Do I really need three of these things?’ Not to mention the fact that clattared code, like a clattered room, is ungainly and makes hard to find what you’re looking for.

Sometimes, though, you find things that you weren’t looking for. Like this fun little example:

String letters;
for (i=65;i<=91;i++)

This little doohickey seems fairly straight forward, doesn’t it? It goes through the letters of the alphabet and produces a string of all the letters one after the other. With a total length of 26 characters (208 bytes.) Nice, simple, effiecent code. Right?

Wrong. Java strings are immutable. Once created, they never, ever change. So that means that the concatenation operator “+=” doesn’t just add another character to the existing string – it creates a whole new one. The old string doesn’t go away (At least not right away. It will get caught in the garbage collector eventually) so instead of having one string “letters” you have this:


A AB<-letters

A AB ABC<-letters

A AB ABC ABCD <-letters

And so on. “letters” always points to the last string created, and eventually the rest of the strings will go away. But a quick calculation shows that in the meantime they take up a combines total of 351 chars. About 2.5 Kilobytes of space. Granted, that’s not much nowadays. But imagine you had this in a loop that ran to 10000? Now we’re talking 40MB of memory (instead of 78k) That’s a bit more of a problem. Make your string increment by two characters at a time instead of one, and we’re up to 193MB (instead of roughly 156k) That’s substantial. Even by today’s standards.

What’s surprising is how often I see things like this in actual code. Not just in our project, but also in other open-source projects and code samples on line. Particularly since this is easy to avoid (use a StringBuffer or StringBuilder). It’s one of those little pitfalls of Java that it seems not all that many people are aware of.