Nokia - It's not just about 'connecting people' anymore...

I still remember my Nokia 2100, that was my primary means of 'connecting' with my friends and family during my engineering studies. It was perfectly suitable for crystal clear calling, messaging, was very sturdy (I don't even remember how many times it has fallen, taped as well, but still it worked just fine...with days worth of battery life...!) and above all, very cheap ! At that time, Nokia was a synonym for mobile.

But from then to now, what changed (or probably did not change) this company to an extent that from a point where they had almost monopoly on this so very booming market, fell to a level that they had to take such drastic measures so as to abandon their 'in-house creation' - the Symbian ! The case of Nokia reminds me of another giants in their industry who have been through the same stage - Ford (a popular quote "Any customer can have a car painted any colour that he wants so long as it is black.").

But why did this happen, was it inability to look beyond the obvious, was it the company structure which was hierarchical to the extent that decision making was next to impossible, or was it the thinking - "Why to change a successful recipe?". Possibly, it was a combination of all of them. As per some sources, Nokia had a prototype of possibly the 'first ever' smartphones designed as early as 2005...but then they rejected any further development on the same then restating their theory that there is not much market for such mobiles...! But then came iPhone and people were drawn to it their new 'touch-technology' which drew considerable interests and even more profits. Even then, Nokia did not realize the shift, or even if they did, they did not perceive it to be 'Big enough to hurt their eco-system'...! But with the introduction of iPhone 3G and 3GS, and other companies also introducing their first prototypes of smartphones in the market, Nokia found that they have postponed the decision way too long not to be in a spot of bother.

At this time, they still were very sure that Symbian is the way to go for Nokia...few reasons I can think of behind this...Firstly, of the past success and the fear of abandoning what has been great (to say the least) and Secondly, the pro-Symbian voices in the company were pretty strong...enough to make sure that they were being heard and Thirdly, the company structure that was not meant to be flexible and agile. But anyway, though late, they did climb on the smartphone market (with the Symbian, ofcourse).

The dynamics of mobile industry had now changed drastically...Nokia were like dinosaurs in an age where beind as nimble and swift as birds was the order of the day ! They had reached a point where though they were still leading the volumes, but the profits were consistently falling. Now they did feel that they needed to take some immediate measures to compensate for this situational disadvantage. And then came Maemo and Meego (in partnership with Intel).

That was certainly a step in the right direction, just the strategy behind promoting this was not well laid out. Nokia wanted Meego to be as a side project (Symbian still being their flagship OS). If we look into the first Maemo device, Nokia N900, it certainly was very impressive...! A positive user experience, refreshingly positive and way more CPU boost than most of the other existing smartphones in the market then. But then, did we hear any followup devices with an improved version of Maemo? Nope, that did not happen...instead what we heard were new smartphones (especially N8) with Symbian - once again! By this time, iPhone had set the standards and moulded the definition of a smartphone such as to suit its needs. To add on to it, the Google Android had improved impressively and pretty quickly with more and more handset manufacturers now joining hands with Android as a preferred software to align with their hardware - but not Nokia.

Now Nokia are in a state where they know that they had to make some revolutionary changes, but what??? They have not been used to being in this situation, neither are they used to change. So they decide to 'finally' part ways with Symbian and partner with Microsoft. Nokia, no doubt, still produce some of the best hardware, but, it is still to be seen how this partnership can succeed. We can now discuss (for and against) about the decision they took as to why they did not go for Android, which has recently outnumbered iPhone on the basis of sales (by volume). But personally, I think they made the best possible decision, given the circumstances to partner with a company with which they share some synergy, be it on the level of organizational composition and corporate decision making or maybe on the company objectives. But considering how dynamic the smartphone market is now, where Moore's Law of technological advancement is basically modified to the core... (not long ago the 1Ghz Hummingbird snapdragon processor and Nvidia Tegra 1Ghz processor were introduced, and now we have new smartphones introduced @MWC 2011 which are running on a dual-core 1Ghz Nvidia Tegra processor. And if this was not enough, Nvidia have announced that they will soon introduced a quad-core mobile processor - codenamed, 'Kal-El', very soon - and all these advancements are just about the processors!), it is still to be seen how will this partnership prosper, but this certainly marks a sad end to a very enterprising life of the very reliable - Symbian !

On a positive note, I still foresee a future for their partnership with Intel on their fledgeling OS, the Meego. At the recently concluded MWC 2011 (at Barcelona), they have unveiled a new tablet running Meego and another netbook which runs an impressively interfaced version of Meego. But if it has what it takes to reach the heights once Symbian conquered, is still to be seen...but I am hopeful...

New language features with JDK7 (Project Coin)

With JDK 7 already passed its Feature Complete stage (M11) and currently in its Developer's Review stage (M12), it will be interesting to list the feature modifications that have been made in this release.

In this blog, I will primarily focus on the language enhancements that have been a part of this JDK release (Project Coin - covered in M11). Some of these I was really looking forward to... :)

1) Strings in Switch: With this release, the Switch statement can be based on String expressions as well. e.g. let us consider the following code:

String s = ...... ;

switch(s) {

case "abc":

processABC():

break;

case "def":

case "ghi"

processDEForGHI();

break;

case "xyz":

processXYZ();

break;

default:

processDEFAULT();

break;

2) Automatic Resource Management: This is a form of 'try-catch' that declares one or more resources (a resource is an object that must be closed manually e.g. OutputStream, InputStream). The scope of these resources is limited to the statement. When the statement completes, normally or abruptly, all of its resources are closed automatically.

Presently, this is how a resource is handled:

static String readLineFromFile(String path) throws IOException {

BufferedReader br = new BufferedReader(new FileReader(path));

try {

return br.readLine();

} finally {

br.close();

}

}

In the case, when both readLine and close invocations throw exception, the latter exception takes priority over the former. As of now, the only way around is to ignore any exception thrown by the close invocation. This can prove to be an issue, more so in case of a writer or OutputStream operation.

With automatic resource management in place, the above sample code will look something like:

static String readLineFromFile(String path) throws IOException {

try (BufferedReader br = new BufferedReader(new FileReader(path))){

return br.readLine();

}

}

3) Improved Type Inference for Generic Instance Creation (diamond): This feature tries to simplify the parametrized assignment. Consider the following example:

Map<String, List<String>> fooMap = new HashMap<String, List<String>>();

This is rather lengthy and can now rather be replaced with:

Map<String, List<String>> fooMap = new HashMap();

Advantage is the simplicity it provides to assignments, hence cleaner code. Conversely, it can be argued that though a code like Map = new HashMap(); looks cleaner, but then for backward compatibility, new HashMap(); denotes a raw type. Hence a sense of conformity is missing as of now. But this is just a minor drawback, I would say. For this reason, a provision has been made to add empty <>, like: Map<String, List<String>> fooMap = new HashMap<>();

4) Simplified Varagrs Method Invocation: As of now, when a user tries to invoke a 'varargs', the compiler generates an "unsafe operation" warning. Now, this warning has been moved from the call site to the method declaration. This significantly reduces the number of warnings reported and suppressed by the programmer.

e.g. Before, a varargs declaration would have been something like:

static <T> List<T> asList(T... elements) { ... }

static List<Callable<String>> stringFactories() {
Callable<String> a, b, c;

...

*// Warning: **"uses unchecked or unsafe operations"*

return asList(a, b, c);

}

Now it will be like:

*// Warning: **"enables unsafe generic array creation"*

static <T> List<T> asList(T... elements) { ... }

static List<Callable<String>> stringFactories() {
Callable<String> a, b, c;

...

return asList(a, b, c);

}

5) JVM level source-code syntax (JSR 292): These primarily include the following:

a) Dynamic Invocation: The interface java.dyn.Dynamic may be used with the static call syntax to form an invoke dynamic call site. The arguments may be of any number and any type. Hence, theoretically java.dyn.Dynamic appears to have infinite number of methods, of every possible name and signature.

e.g.

Object obj = Dynamic.getDynamicLink();

An invoke dynamic call is linked to a target method under control of an application-defined bootstrap method and the linkage state is defined by a method handle (explained below) with the same type descriptor as the call itself.

b) Method Handle Invocation: Method handles (java.dyn.MethodHandle) provides the linkage state behind any invoke dynamic instruction. Like Dynamic calls, a method handle also accepts any number of type and signature, which means that it can also have infinite number of calls to method "invoke".

e.g.

MethodHandle mh = ...

mh.invoke();

c) Exotic Identifiers: The identifiers can now be any sequence of characters (with minor restrictions). Certainly this will enable in more user-friendly naming and hence cleaner and more maintainable code.

e.g.

int #"valid variable name" = 100;

System.out.println(#"valid variable name"); //this will print 100

d) Conversion rule for Interface Dynamic: Type Dynamic also serves a purpose of a wildcard type. As a mere reference, it can be freely converted to any other type and to object and as a cast, it can be converted to any type. Along with invoke dynamic syntax, it allows dynamic method calls chaining.

e.g.

Dynamic dynObj = (any type of expression);

Object obj = x.foo("ABC").bar(100).baz();

The JSR292 changes basically allow Java to interoperate with new JVM languages. It also enables Java to serve well as a language implementation or systems programming language.

These are the language changes that I have come across with JDK 7. More information can be found at http://blogs.sun.com/darcy/entry/project_coin_final_five

I am certainly now looking forward for JDK7 to be officially released (should be sometime in the second half of 2011). Enjoy coding... :)