Does Google Nexus 4 Orange Blinking Light creating lots of tension in your head ???

Hey guys...is Google Nexus 4 blinking orange light giving you jitters and cramps in your head and you have charged it for lots and lots of hours but it is still being the dumb ass and keep doing the same...well then here is the bumper for it to solve its idiotic nature. Here is the 3 steps procedure:

• Step 1: Unplug it if you are still being positive and charging it.
• Step 2: Press and hold Power button.
• Step 3: Plug it by still keeping power button pressed and after 60 seconds leave the button, after 20 min or so you will see the white charging icon and its done...your phone is back from being a dumb ass.

Why this happens ?

There is no one answer but some blogs suggests which i believe is that there is a Deep Hibernation mode for battery in Nexus 4 which leads it to show this dumb behavior and this behavior is triggered if your phone battery goes off and you don't charge it for couple of hours. For me this happens if i leave it for more than 6-8 hours on a discharged battery.

I hope this helps someone who is feeling to suicide because of this behavior of his Nexus 4....but cheers and no need of that. Keep smiling.

Semantic Versioning

Semantic versioning is a simple versioning scheme suggested by OSGi Alliance where it conveys much more meaning about what’s changing than normal versioning schemes do.

Following are the key points:

• Every version consists of four parts: major, minor, micro, and qualifier (Major.Minor.Micro.Qualifier).
  
• A change to the major part of a version number (for example, changing 2.0.0.0 to 3.0.0.0) indicates that the code change isn’t backwards compatible. Removing a method or changing its argument types is an example of this kind of breaking change.
  
• A change to the minor part (for e.g., changing 2.0.0.0 to 2.1.0.0) indicates a change that is backwards compatible for consumers of an API, but not for implementation providers. For example, the minor version should be incremented if a method is added to an interface in the API, because this will require changes to implementations.
  
• If a change doesn’t affect the externals at all, it should be indicated by a change to the micro version (for e.g., changing 2.0.0.0 to 2.0.1.0). Such a change could be a bug fix, or a performance improvement, or even some internal changes that remove a private method from an API class. Having a strong division between bundle internals and bundle externals means the internals can be changed dramatically without anything other than the micro version of the bundle needing to change.
  
• Finally, the qualifier is used to add extra information, such as a build date (for e.g. changing 2.0.0.0 to 2.0.0.110813, 110813 represents 08-Nov-2013) .

Among the version sections defined above, many of the product/component writers prefer Major, Minor and Micro and in some cases even Micro is left back and just add to your general knowledge Google does not follow any (WTH!!). So, its up to you as how you take it. For me, i love it.

JDK 8 Striking Features - Part 1

Finally, i got some good free time and thought to utilize it looking into the progress Java achieved. So, when looking into tutorial pages i saw a good thing to have in JDK 8.0 which will be launched soon and that is Aggregate Operations on Collections.

Here are the details:--

In JDK 8 a new and preferred method of iterating over a collection will be introduced and that is to obtain a stream and perform aggregate operations on it. Aggregate operations are often used in conjunction with lambda expressions to make programming more expressive, using less lines of code. The following code sequentially iterates through a collection of shapes and prints out the red objects:

myShapesCollection.stream()
.filter(e -> e.getColor() == Color.RED)
.forEach(e -> System.out.println(e.getName()));

Likewise, you could easily request a parallel stream, which might make sense if the collection is large enough and your computer has enough cores:

myShapesCollection.parallelStream()
.filter(e -> e.getColor() == Color.RED)
.forEach(e -> System.out.println(e.getName()));

There are many different ways to collect data with this API. For example, you might want to convert the elements of a Collection to String objects, then join them, separated by commas:

    String joined = elements.stream()
    .map(Object::toString)
    .collect(Collectors.joining(", "));

Or perhaps sum the salaries of all employees:

int total = employees.stream()
.collect(Collectors.summingInt(Employee::getSalary)));

These are but a few examples of what you can do with streams and aggregate operations. For more information and examples, you can go to Java Site

The Collections framework has always provided a number of so-called "bulk operations" as part of its API. These include methods that operate on entire collections, such as containsAll, addAll, removeAll, etc. Do not confuse those methods with the aggregate operations that were introduced in JDK 8. The key difference between the new aggregate operations and the existing bulk operations (containsAll, addAll, etc.) is that the old versions are all mutative, meaning that they all modify the underlying collection. In contrast, the new aggregate operations do not modify the underlying collection. When using the new aggregate operations and lambda expressions, you must take care to avoid mutation so as not to introduce problems in the future, should your code be run later from a parallel stream.

In my next post i will introduce Lambda Expressions in Java which is again a super striking feature to be introduced in JDK 8.