Java Singletons don’t exist.

*** Posted on https://bigendian.wordpress.com 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,

B.E.

Advertisements

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

*** This post belongs to https://bigendian.wordpress.com, 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. 🙂

B.E.

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

***This post belongs to https://bigendian.wordpress.com. 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();
System.out.println(aMyClass.getT());

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:

java.io.EOFException
 at java.io.ObjectInputStream$PeekInputStream.readFully(ObjectInputStream.java:2281)
 at java.io.ObjectInputStream$BlockDataInputStream.readShort(ObjectInputStream.java:2750)
 at java.io.ObjectInputStream.readStreamHeader(ObjectInputStream.java:780)
 at java.io.ObjectInputStream.<init>(ObjectInputStream.java:280)

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

java.lang.ClassNotFoundException: com.mycomp.myprod.server.common.MyClass
at java.net.URLClassLoader$1.run(URLClassLoader.java:200)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:188)
at java.lang.ClassLoader.loadClass(ClassLoader.java:307)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:301)
at java.lang.ClassLoader.loadClass(ClassLoader.java:252)
at java.lang.ClassLoader.loadClassInternal(ClassLoader.java:320)
at java.lang.Class.forName0(Native Method)
at java.lang.Class.forName(Class.java:247)
at java.io.ObjectInputStream.resolveClass(ObjectInputStream.java:604)
at java.io.ObjectInputStream.readNonProxyDesc(ObjectInputStream.java:1575)
at java.io.ObjectInputStream.readClassDesc(ObjectInputStream.java:1496)
at java.io.ObjectInputStream.readOrdinaryObject(ObjectInputStream.java:1732)
at java.io.ObjectInputStream.readObject0(ObjectInputStream.java:1329)
at java.io.ObjectInputStream.readObject(ObjectInputStream.java:351)

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 (MyClass.java).

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.

B.E.

Do you understand the words that are coming our of my keyboard?

I happened across an interesting article about OpenXava today. OpenXava is a platform for Java Enterprise applications that promises to simplify code development, which is a great idea. But what struck me about the article was actually the opening paragraph:

OpenXava 3.1.3 is a framework to develop Java Enterprise applications in a different way: OpenXava avoids MVC. It’s a JPA Application Engine in that you provide only your POJOs annotated with JPA and you obtain an application ready for production.

Productivity
With OpenXava, you only need to write your model, POJOs with annotations. You do not need to write the view, and the controller (for CRUD, printing, etc) is reused.

If you are scratching your head at this and reaching typing in Google for translation, you are not alone. Sure, it makes it sound all hi-techie and complicated when there are a ton of acronyms and abbreviations, but that also makes it harder to understand. What the guy meant was that you can use plain Java to create enterprise applications without having to go through a lot of the grunt work. As far as  introductions go, I think that would have been sufficient. There really is no need to make things sound more complicated then they are, and don’t always assume your readers know what you’re talking about. For any one who is still interested, the full article is HERE.

On the same topic, I’ve been meaning to write a post about the wonders of commenting your code, and why it’s so important to do it, and do it right. But then I discovered 13 tips to comment your code – a wonderful piece originally written in Spanish by José M. Aguilar in his blog, and translated into English by Tidarat Chamnasri Timm Martin (Thanlks, Tidarat, For the correction). It’s something that anyone who write code should read at least once a week. Or possibly (in the case of certine people) have ingraved into their forearm.  🙂

And finally, for anyone who hasn’t seen it, I’d recommand going to http://www.tengrandisburiedthere.com. If you don’t get it, look here.

Good Weekend,

B.E.

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.

B.E.

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++)
  letters+=String.valueOf((char)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<-letters

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.