Well it doesn’t do to leave your system unpatched, I thought, and if Microsoft has updates for my machine, and labels them “important” I should probably install them right away, right? Especially if they have gone out of their way and released a second update package in the same week, got to be crucial.

Not so much. Turns out that KB970653 - the update in question – was an update to the time zone feature in my windows system. Apparently the people at Microsoft were so worried that I’d get the time wrong on my system that they felt the need to push out a special update package, and make me restart my system, just so that the timer wont be off.

Now I agree that the system time functions are important, especially if you are running database systems or servers. But for most of us, simple mortals who just use our computers for everyday life. Is all this hassle really necessary? Couldn’t this wait for the normal Update Tusday cycle? It makes me wonder what other junk Microsoft pushes down the pipe just because no one actually bothers to check if those “important” and “critical” updates really are all that crucial. Those of use who were around a few years ago probably remember Microsoft’s “Critical” update KB833404 that was put out in 2004 for every MS Office product there was. You’d think that a “critical” update for ALL of Office meant that they found and fixed some gaping security hole or something, but no, that critical update did nothing more than remove two swastika symbols that ended up in the wrong font. I’m not making this up.

Personally, I opted not to install the important update just yet. When I’m done with my vacation, and the laptop gets shutdown anyway so I can take to work, then I’ll do it. Until then I will stay with me, alas, not accurate time zone info. In the meantime, if anyone in Microsoft is reading this, I’d like to offer one thought: Before you randomly label updates as important and critical, you might want to take a moment to re-read the story about the boy who cried wolf. Not every update deserves panic mode treatment. Thanks.

B.E.

I’m mentioning this because the June issue of Scientific American Magazine published a really interesting article on the topic titled “How Hackers Can Steal Secrets from Reflections” which explains this kind of attack in a simple and interesting language. It’s a little far fetched, but well worth reading.

B.E.

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);

try{
     Method getinst = cls.getMethod("getInstance",null);
     obj = getinst.invoke(null, null);
     }catch(NoSuchMethodException n){
     try {
         obj = cls.newInstance();
     } catch (InstantiationException e) {
      e.printStackTrace();
     }
 }
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,

B.E.

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.

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.

The net is abound with buzz nowadays about the aannouncement of a Google “Operating System” due to come out the second quarter of 2010. Yawn..

Beyond the discussion of what qualifies this as an Operating System, for which I will direct you to two excellent articles by TechCrunch and The Register (Caution: colorful language), there is also the question of what the product actually is. According to Google, the Chrome OS is “Google Chrome running within a new windowing system on top of a Linux kernel.” In other words: Install Linux, Install Chrome, take away anything that isn’t Chrome, and expect who ever is using this to only use tools that run in Chrome. Seems to me this should take about a week for a competent System guy to do, assuming he has to write his own scripts.

So what’s the big deal here? The “new Windowing system”? Gnome, KDE, and the rest aren’t good enough for you, you need something that will launch Chrome automatically without showing a Desktop first? I mean seriously, what are they going to be spending a year on?

The answer is as simple as it is sad: they are going to spend the next year on trying to make Chrome do things the way a real OS does, and on trying to make Web-apps function like real apps. With all kinds of hocus pocus like HTML 5, Google Gears, and G-D knows what else, they’re going to try and develop a comparable platform for running the programs you need inside a browser.   I doubt they’ll succeed, and I seriously doubt that they can do it in a year.

And that’s the bottom line. No one really cares is the OS they use come from Microsoft, Mac, Linux, or Ed’s computer shopp and live tackle, they simply want to install their applications (that they’ve been using for years) and have them work. Period. This is the reason that after a great valiant run at Linux, I came back to Windows. It let me do the things I wanted, and have been doing for over a decade, without having to re-learn and re do everything. Trying to get everyone to shift paradigms and move to Google Docs is one thing (and a daunting task at that). The fact that Google Docs can’t do everything that office can is completely different. In the larger scheme of the corporate world, a $200 saving on a computer with a free OS is nothing compered to the amount of time, and hence money, wasted on trying to relearn years of established ways to do things.

There’s even more to is than that. As the Register points out:

But it’s not just Office that will keep Microsoft’s hold on the PC market. Can you replace Active Directory with a web app? Is there a site I can visit to connect to my office’s shared printer? What do you mean World of Warcraft doesn’t run in the browser? How do I play a DVD in Google Chrome?

And he’s absolutly right: The greatness of a true OS is that it can run ANYTHING, not just thing that are written in the limited context of the Internet. And if a program is installed on my hard drive it will run with or without a network connection, and can access and modify the files on my drive without the fear that sudden server congestion will break it. Until ChromeOS can claim even a little of that, it is not Operating System, it’s a non-event.

Good Weekend,

B.E.

***This post belongs to http://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.

Teen Releases First Jailbreak App for iPhone 3GS

You’d figure Apple would learn eventually and stop trying to lock down it’s products… Oh, wait.

B.E.

I haven’t had much time to update in the past couple of days (lots of fun Java work) but I wanted to share a small site which I think is a serious contender to the “Epitome of Gimmick” award: http://blackle.com/

The concept is simple: Darkness takes less energy than light, therefore, if we make our screen entirely black, it will take less energy than if it were white (like Google).

It’s a gimmick for two reasons.

A. Depending on your screen, black may actually take more energy than white, and

B. If you had said this five years ago, people would have looked at you like you’re nuts and asked you if you didn’t have anything better to do. If you say it five years from now, people would look at you like you’re nuts and ask we don’t you invest your energy in some REAL energy saving solutions.  But now, right now, people are already concerned enough about the environment to listen to things like this, and clueless enough to actually follow them. This leads to a site which has no distinction other than its color scheme becoming a major destination on the Net.

Something that isn’t special, but has something that looks special enough to attract your attention. Yup, that a gimmick alright. Personaly, I’m waiting for the IPhone app that would blacken the touch screen…

Ok, Back to JavaLand.

B.E.

Go ahead. Type that into Google, bing, or Wolfarm alpha, and see what you get. Chances are it’ll be a long laundry list having to do with Obama picking his surgeon general, KFC, or chicken jokes. In fact, you will get a whole load of matches to your query, but you will not one simple thing: an answer.

This is, of course, because search engines don’t understand questions. They simply scan your search terms for keywords and try to give you relevant pages. They do some rudimentary grammar analysis to try and determine the subject of the query (IE the thing you are actually looking for) but more often than not, they get it wrong (which is why you get more entries about chicken then the surgeon general). Search engines have a hard time with descriptions, too. A ‘man who looks like a thing’ is the sort of thing that a search engine simply can’t handle. And finally, search engines can get easily confused in determining what pages to return that might contain an answer (Consider this post, for example, it has links to search engines, chicken jokes, and observations about grammar. If you had to quantify it by keywords, you’d end up with some mighty odd matches)

I say this because there has been a trend recently of creating “answer engines” – search engines that can understand your question and miraculously supply you with the answer. It started a few years ago with “ask Jeeves” (now part of ask.com) and had its latest arrivals in the much publicized Wolfarm Alpha and the bing “decision engine”. Sadly it seems that hype aside, there really is no noticable difference between a search engine and a answer engine, with the possible exception of Wolfarm – the first engine that has the desency to tell you when it doesn’t understand what you want.

I’m not faulting search engines developers, mind you. Understanding plain-English questions is a hugh and daunting task, and the field is really only init’s infancy. Search engines have gotten a lot better over the past few years, and will continue to improve (and users will continue to get better in searching, which is a different topic for a different day.) But we’re still far far away from the day when all the knowledge of the Internet is at our fingertips. Search engines can fill in many details, but they’re no replacment for a structured approche to learning,  no replacement for simple thirst for knowledge, and no good in trivia. At least, not yet.

Big Endian.

P.S.

For anyone who’s wondering, the answer is

C. Everett Koop

a great name, if I ever heard one.