Sunday, July 14, 2013

Software Engineers Reactions


Thank you #Brayan for sharing the content.

When I show the boss that I have finally fixed this bug

When the project manager enters the office

When I'm deploying code to production

When I try to fix a bug at 3 in the morning

When my regex returned exactly what I expected

When a friend of mine asks me to fix his website built with Joomla

When I'm told that the module on which I have worked all the week will never be used

When the code that I have not tested on dev works perfectly in production

When the sales people announce they have sold our product to the customer

When I apply a new CSS for the first time

When sysadmin finally gives us the root access

When I launch my script for the first time after several hours of development

When I go off for the weekend while everyone else is still trying to fix bugs

When the app goes into beta and the first bug reports arrive

Wednesday, July 10, 2013

Some of the new features in JDK 8


Oracle has really pushed for JDK 8 release, trying to keep to their word of releasing it within two years. We are currently at M7 (b94) which was released on 2013/06/13 I think its right about time to talk a bit on some of the interesting new features which are available.

  • Remove the Permanent Generation
  • Lambda expressions
  • Parallel Array Sorting
  • New Date & Time API
  • Define a standard API for Base64 encoding and decoding
  • New Javascript engine.


Remove the PermGen

The PermGen (Permanent Generation) space has been completely removed and replaced by a new space called Metaspace.

The consequences of the PermGen removal is that the PermSize and MaxPermSize JVM arguments will be ignored with warning messages if present when starting the JVM

However that doesn't mean you won't have to worry about the class metadata memory footprint and it does not eliminate class and Classloader memory leaks (if there any). Most allocations for the class metadata are now allocated out of native memory. By default class metadata allocation is limited by the amount of available native memory.

I really think this is a bad idea, currently if do have a memory leak in PermGen we end up only crashing the JVM and we can easily restart the JVM but if we end up filling the native memory we might end up crashing the server, but a new flag is available (MaxMetaspaceSize), allowing you to limit the amount of native memory used for class Metadata. The Metaspace will dynamically re-size depending on the application demand at runtime. There is obviously some garbage collection involved but I don't think that there is much to worry about here unless you have a problem of  Classloader memory leak. We just need to wait and see what are the new problems this is going to introduces.


Lambda expressions

This is something I was really looking forward to for couple of years now, I think this would be the Scala killer Winking smile

Lets get something straight here, Lambda does not let you do something new which cannot be done in JDK 7 < it just gives you a better (less lines) way to represent a block of code. Until JDK 8, the way to achieve processing of a method via another method is to pass an object. which is similar to a callback method or pass an anonyms override object.

   1:  action.execute(new Runnable() { 
   2:      @Override 
   3:      public void handle(Event event) { 
   4:          System.out.println("Hi There !!"); 
   5:      } 
   6:  }); 

The issue with callbacks is that it leads to verbose code. Like you would write 5 lines of code when the real job is in 1 of these 5 lines.

With JDK 8 you will have something similar to the following :

   1:  action.execute( 
   2:      event -> System.out.println("Hi There !!") 
   3:  ); 

You can do method referencing, meaning you can pass a method as an argument to another method. Method references work differently between static and non static methods.

public class Utils implements Comparable<MyObject> { 
    public static int compareByLength(String in, String out){ 
        return in.length() - out.length(); 
    public int compareTo(MyObject obj) {
        return 1
public class RunThis {
    public static void main(String[] ar) {
        String[] args = new String[] {"Microsoft: Rocks", "Linux: Wow", "Apple: Sucks"} 
        Arrays.sort(args, Utils::compareByLength);
        Utils util = new Utils();
        Arrays.sort(args, util::compareTo);

There are many other things to discuss about lambda, but that’s for another post.


Parallel array sorting

Arrays#parallelSort this was introduced newly in JDK8

Arrays#parallelSort uses Fork/Join framework introduced in Java 7 which assigns the sorting tasks to multiple threads available in a pool and joins them in the end

Following methods are available :

parallelSort(byte[] a) 
parallelSort(byte[] a, int fromIndex, int toIndex) 
parallelSort(char[] a) 
parallelSort(char[] a, int fromIndex, int toIndex) 
parallelSort(double[] a) 
parallelSort(double[] a, int fromIndex, int toIndex) 
parallelSort(float[] a) 
parallelSort(float[] a, int fromIndex, int toIndex) 
parallelSort(int[] a) 
parallelSort(int[] a, int fromIndex, int toIndex) 
parallelSort(long[] a) 
parallelSort(long[] a, int fromIndex, int toIndex) 
parallelSort(short[] a) 
parallelSort(short[] a, int fromIndex, int toIndex) 
parallelSort(T[] a) 
parallelSort(T[] a, Comparator<? super T> c) 
parallelSort(T[] a, int fromIndex, int toIndex) 
parallelSort(T[] a, int fromIndex, int toIndex, Comparator<? super T> c) 

New Date & Time API

Nothing much to talk about here, but only the fact most of the current features available in JodaTime API is available natively in JDK8


Define a standard API for Base64 encoding and decoding

Again nothing much here everything available Base64 library (part of apache commons) So this feature is simply to implement a standard API for Base64 and to avoid people to have to use unsupported classes such as sun.misc.BASE64Encoder and sun.misc.BASE64Decoder.


New JavaScript engine

JDK 8 will juice JavaScript performance on the Java Virtual Machine using Project Nashorn, a Javascript engine that will use the JVM libraries and will replace the existing Rhino engine. Design and implement a new lightweight, high-performance implementation of JavaScript, and integrate it into the JDK. The new engine will be made available to Java applications via the existing javax.script API, and also more generally via a new command-line tool.