Tech

20141127

Java's parametrize Lambda;

Lambda is a new feature on the java se - JDK 8; yeat not implemented on the java EE specs. This now tool provides a lot more flexibility for the java programmers to code reuse, but also can generate unnecessary complexity;

All you really need is an interface with a single method. The annotation @FunctionalInterface (java.lang.annotation.FunctionalInterface - JDK 8), only enforces that the interface must have one and only one abstract method, but you could live without it.  To me, is just to tell others programmers not to declare anything else;

Example:
@FunctionalInterfaceinterface Calculator{    double calculate(int x , int y); }
or
interface Calculator{    double calculate(int x , int y); }
Both Works the same, and a consequence it limits other Object Oriented aspect as method overloading; 

Bad Example: 
interface Calculator{    double calculate(int x , int y);     double calculate(Long x , int y); }
Wrapping also seems not to have problems with Lambda expressions:

package lambda.expression;
import java.util.ArrayList;
import java.util.Iterator;
import java.util.List;

//Lambda primitive type
@java.lang.FunctionalInterface
interface Calculator {
    double calculate(long x, int y);
}

//lambda generic Object
@java.lang.FunctionalInterface
interface ObjectImpl<E> {
    E doOString(E obj1, E obj2);
}

public class Test {
    public static void main(String[] argv) {
        //This is a very simple example; with declaration type and passing the expression;
        Calculator calc = (long x, int y) -> Math.min(x, y);
        System.out.printf("%6.2f\n", calc.calculate(255, 7));
       
        //A little more complex, is the use of collection;
        List<Calculator> listCalc = new ArrayList<>();
        listCalc.add((x, y) -> x + y);
        listCalc.add((x, y) -> x - y);
        listCalc.add((x, y) -> x / y);
        listCalc.add((x, y) -> x % y);
        listCalc.add((x, y) -> Math.hypot(x, y));
        Iterator<Calculator> interate = listCalc.iterator();
        while (interate.hasNext()) {
            Calculator calculator = interate.next();
            System.out.printf("%6.2f\n", calculator.calculate(255, 7));
        }
        //to make your day, Generics is here to add some more complexity;
        ObjectImpl<String> objectImpls = (obj1, obj2) -> obj1 + obj2;
        String result = objectImpls.doOString("Hello ", "World!!");
        System.out.println(result);
        //Adding with Integer Object and wrappers;
        ObjectImpl<Integer> objectImplsNum = (obj1, obj2) -> obj1 + obj2;
        Integer resultint = objectImplsNum.doOString(new Integer(2),3);
        System.out.println(resultint);
       
    }
}

The results: 

run:
  7.00
262.00
248.00
 36.00
  3.00
255.10
Hello World!!
5
BUILD SUCCESSFUL (total time: 2 seconds)

Lambda like break, continue, label and other features, can turn your code more complex; but its here to stay, and we should understand how it works and use it with precaution;  



20131217

Java Mission Control (jmc) Crashing: SIGSEGV at C [libsoup-2.4.so.1+0x6dab1] soup_session_feature_detac

I was checking around the new JMC, that comes bundle with the jdk1.7_45; this tool is like a mix of Jrockit Mission Control and jvisualvm. As for now, does not have as many tools as offers the JRMC and the connection is done through JMX, just like you would do while connecting with jvisualvm. 

But, to spoil my fun while running the ./jmc I got :



A fatal error has been detected by the Java Runtime Environment:
#
# SIGSEGV (0xb) at pc=0x0000003119a6dab1, pid=9245, tid=140539766241024
#
# JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build 1.7.0_45-b18)
# Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode linux-amd64 compressed oops)
# Problematic frame:
# C [libsoup-2.4.so.1+0x6dab1] soup_session_feature_detach+0x11
#
# Core dump written. Default location: /usr/java/jdk1.7.0_45/bin/core or core.9245

Yes, its a nice coredump, and with a filedump in which I got the header above. By looking at the filedump, I could check that this .so lib was being use by an or.eclipse.swt.internal.webkit:

Stack: [0x00007fd1f6c7f000,0x00007fd1f6d80000], sp=0x00007fd1f6d7cb20, free space=1014kNative frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)C [libsoup-2.4.so.1+0x6dab1] soup_session_feature_detach+0x11
Java frames: (J=compiled Java code, j=interpreted, Vv=VM code)j
 org.eclipse.swt.internal.webkit.WebKitGTK._soup_session_feature_detach(JJ)V+0j org.eclipse.swt.internal.webkit.WebKitGTK.soup_session_feature_detach(JJ)V+9j org.eclipse.swt.browser.WebKit.create(Lorg/eclipse/swt/widgets/Composite;I)V+920j org.eclipse.swt.browser.Browser.<init>(Lorg/eclipse/swt/widgets/Composite;I)V+81j org.eclipse.ui.internal.intro.impl.presentations.BrowserIntroPartImplementation.createPartControl(Lorg/eclipse/swt/widgets/Composite;)V+19j org.eclipse.ui.internal.intro.impl.model.IntroPartPresentation.createPartControl(Lorg/eclipse/swt/widgets/Composite;)V+74j org.eclipse.ui.intro.config.CustomizableIntroPart.createPartControl(Lorg/eclipse/swt/widgets/Composite;)V+64j org.eclipse.ui.internal.ViewIntroAdapterPart.createPartControl(Lorg/eclipse/swt/widgets/Composite;)V+9j org.eclipse.ui.internal.ViewReference.createPartHelper()Lorg/eclipse/ui/IWorkbenchPart;+406j org.eclipse.ui.internal.ViewReference.createPart()Lorg/eclipse/ui/IWorkbenchPart;+5j org.eclipse.ui.internal.WorkbenchPartReference.getPart(Z)Lorg/eclipse/ui/IWorkbenchPart;+65j org.eclipse.ui.internal.Perspective.showView(Ljava/lang/String;Ljava/lang/String;)Lorg/eclipse/ui/IViewPart;+16j org.eclipse.ui.internal.WorkbenchPage.busyShowView(Ljava/lang/String;Ljava/lang/String;I)Lorg/eclipse/ui/IViewPart;+59j org.eclipse.ui.internal.WorkbenchPage$20.run()V+21

Investigating the issue with eclipse bugs, I came across this Bug 404776; Which nicely provided a simple workaround by just adding two new parameters:

-Dorg.eclipse.swt.browser.DefaultType=mozilla
-Dorg.eclipse.swt.browser.XULRunnerPath=/urs/lib64/xulrunner
The XULRunnerPath should be set to the actual xulrunner on your OS. At this case, mine is a 64bits Fedora 19...

To Java Mission Control take these parameters, you need to edit the following file:

/usr/java/jdk1.7.0_45/lib/missioncontrol/configuration/config.ini

Just need to append those two parameters at the end of config.ini file and the Java Mission Control should start without a problem.

#echo org.eclipse.swt.browser.DefaultType=mozilla >> /usr/java/jdk1.7.0_45/lib/missioncontrol/configuration/config.ini
#echo org.eclipse.swt.browser.XULRunnerPath=/urs/lib64/xulrunner/ >> /usr/java/jdk1.7.0_45/lib/missioncontrol/configuration/config.ini

# --> root user...