Java 8

^{JSR 337, features, milestones}

Upcoming release, not yet final.

Language changes:

·         lambda expressions (JSR 335, includes method handles)

·         continuation of Project Coin (small language improvements)

·         annotations on Java types

Library changes:

·         Improved Date and Time API

Java 7

^{JSR 336, features and enhancements}

Language changes:

·         Project Coin (small changes)

·         switch on Strings

·         try-with-resources

·         diamond operator

Library changes:

·         new abstracted file-system API (NIO.2) (with support for virtual filesystems)

·         improved concurrency libraries

·         elliptic curve encryption

·         more incremental upgrades

Platform changes:

·         support for dynamic languages

Java 6

^{JSR 270. features and enhancements}

Mostly incremental improvements to existing libraries, no new language features (except for the@Override snafu).

Java 5

^{JSR 176, features and enhancements}

Language Changes:

·         generics (that's the big one)

·         annotations

·         varargs, enhanced for loops (for-each)

Library changes:

·         concurrency utilities in java.util.concurrent

Java 1.4

^{JSR 59}

Language changes:

·         the assert keyword

Library changes:

·         regular expressions support

·         NIO

·         integrated XML handling

Java 1.3

Mostly minor improvements, really.

Platform changes:

·         HotSpot JVM: improvement over the original JIT

Java 1.2

Language changes:

·         the strictfp keyword

Library changes:

·         a unified collections system

·         Swing as a new UI-System on top of AWT

Platform changes

·         a real JIT, greatly improving speed

Java 1.1

Language changes:

·         inner classes

Library changes:

·         AWT event changes

·         JDBC, RMI

·         reflection

Java 1.0

Initial release, everything is new ;-)

Code examples for new features in Java 1.7

Most of what is below come from the excellent article from Joe Wright on his blog about New language features in Java 7

Language support for collections

This is all about writing less code when you create a List, a Set or a Map. You don't have to instantiate the Object and then add the element to the Collection. You can now do it in 1 line.

List<String> list = ["item"];
String item = list[0];

Set<String> set = {"item"};

Map<String, Integer> map = {"key" : 1};
int value = map["key"];

Automatic Resource Management

Annoyed to have verbose code because of try / catch statement. You will love this one.

Indeed, this:

BufferedReader br = new BufferedReader(new FileReader(path));
try {
   return br.readLine();
} finally {
   br.close();
}

Become this:

try (BufferedReader br = new BufferedReader(new FileReader(path)) {
   return br.readLine();
}

Improved Type Inference for Generic Instance Creation (diamond)

Same thing, today you specify the Generic when you declare the interface of your object and then you have to repeat yourself when you instantiate the object. You won't have to now as you can do:
Map<String, List<String>> map = new HashMap<>();

Underscores in numeric literals

Not sure this one will be useful to lot of people. You can do:

int billion = 1_000_000_000;

Strings in switch

Nothing to explain here, the title says it all.


String availability = "available";
switch(availability) {
 case "available":
    //code
    break;

  case "unavailable":
    //code
    break;

  case "merged":
    //code

  default:
    //code
    break;
}

Portlet  to  Portlet  Communication

Introduction

The first version of the portlet specification, JSR-168/portlet1.0, did not include any support for Inter Portlet Communication. The second version, JSR-286/ portlet2.0, which is supported for IPC  Mechanism.IPC  is made easy  with JSR-286 to share the data between two portlets. Using IPC mechanisms, we can share the data from ACTION to VIEW phase and  VIEW-VIEW Phase.

There are 3  ways  to  share  the  data   between  2  portlets.

1.      Portlet session

2.      IPC  Mechanisms

2.1             Public Render Parameters

2.2             Event

2.3             Client-Side IPC

3.      Cookies

1.      1. Portlet  Session

By default , Each war has its own session and will not be shared with other  wars. Liferay provides a mechanism by which Portlets can share session attributes across WARs.

A PortletSession is created for each user per portlet application. This makes the PortletSession useful for communicating all user related information among different portlets in the same portal application.

Step 1:  set below attributes in Portlet1

liferay-portlet.xml :

<portlet>

<private-session-attributes>false</private-session-attributes>

</portlet>

     Step 2:  To set the Session:

PortletSession session = renderRequest.getPortletSession();

session.setAttribute("sessionValue",some-value , PortletSession.APPLICATION_SCOPE);

Step 3 : Get the Session Value in Portlet2

PortletSession ps = renderRequest.getPortletSession();

String tabNames = (String)ps.getAttribute("sessionValue ",ps.APPLICATION_SCOPE);

2.      IPC Mechanism

2.1 Public Render Parameter :   IPC ( Inter Portlet Communication)  : 

In JSR 168, the render parameters set in processAction is only available in the render of the same portlet. With the Public Render Parameters feature, the render parameters set in the processAction of one portlet will be available in render of other portlets also.

By adding the following property in portlet-ext, we can enable portlets to share render states with other portlets that are on different pages:

portlet.public.render.parameter.distribution=ALL_PORTLETS

Step 1:  Add below attribute in “Sender-Portlet”

           

            <portlet-app>

<portlet>

            <supported-public-render-parameter>

 id1

</supported-public-render-parameter>
</portlet>

<public-render-parameter>

  <identifier>id1</identifier>

<qname xmlns:x="http://abc.com/userId">x:param1</qname>

</public-render-parameter>

</portlet-app>

Note: We  can declare a list of public paramters for a portlet application.

Step  2:

 We can set render parameter in the processAction() method by using the defined public render parameter identifier as the key.

response.setRenderParameter("id1", “someIdValue”);

e.g.

public void processAction(ActionRequest  request, ActionResponse response)

throws IOException, PortletException  { ........

response.setRenderParameter("id1", “someIdValue”); ........

}

Step  3 : Receiver Portlet Portlet  “portlet.xml”

Specify the render parameter the portlet would like to share in the portlet section.

<portlet-app>
< portlet >

< portlet-name >PortletB< /portlet-name >

< supported-public-render-parameter >id1< /supported-public-render-parameter >

< /portlet >

<public-render-parameter>

  <identifier>id1</identifier>

<qname xmlns:x="http://abc.com/userId">x:param1</qname>

</public-render-parameter>

</portlet-app>

Step 4 :

A portlet can read public render parameter using following method

request.getPublicParameterMap()

Note: Public render parameters are merged with regular parameters so can also be read using

request.getParameter(“id1”);

           

Step 5:

A portlet can remove a public render parameter by invoking following methods.

response.removePublicRenderParameter(“id1”)

3         Event  :   IPC ( Inter Portlet Communication)  :

 

 
Portlet events that a portlet can receive and send.

In JSR-168 :
The only way to achive eventing was through portlet session.
Limitation : Portlet has to be in the same web application.

In JSR-286 :
JSR 286 (Portlet 2.0) defines a lifecycle for events, so that eventing is possible between portlets that are in different web applications.

By adding the following property in portal-ext, we can enable portlets to send and receive events from other portlets that are on different pages

            portlet.event.distribution=ALL_PORTLETS

Step 1: Sender Portlet

portlet.xml

-----------

The portlet standard defines a way of telling the portlet container  which portlet is responsible for sending an event.

Add this inside <portlet> tag:

         <portlet-app>

<portlet>

                        <supported-processing-event xmlns:x='http://liferay.com'>

<qname>x:empinfo</qname>

</supported-processing-event>

             </portlet>

<event-definition xmlns:x='http://liferay.com'>

<qname>x:empinfo</qname>

<value-type>java.lang.String</value-type>

</event-definition>

         </portlet-app>

Step 3 : Set the event in process action:

 javax.xml.namespace.QName qName =

new QName("http://liferay.com", "empinfo", "x");

response.setEvent(

qName,

"Hai You have received Event Data sent from Sender Portlet");

Step 4: Listner Portlet

portlet.xml:

-----------

<portlet-app>

<portlet>

<supported-processing-event xmlns:x='http://liferay.com'>

                                    <qname>x:empinfo</qname>

                        </supported-processing-event>

</portlet>

<event-definition xmlns:x='http://liferay.com'>

<qname>x:empinfo</qname>

            <value-type>java.lang.String</value-type>

</event-definition>

</portlet-app>

Step 5: get the EVENT:

This Even will be called after processAction as shown in the picture:

Lifecycle for IPC Event:

             

@javax.portlet.ProcessEvent(qname = "{http://liferay.com}empinfo")

 public void handleProcessempinfoEvent(

javax.portlet.EventRequest request, javax.portlet.EventResponse response)

throws javax.portlet.PortletException, java.io.IOException {           

        javax.portlet.Event event = request.getEvent();

        String value = (String) event.getValue();

      

            System.out.print("value in process event>>>>>>>>>" + value);

            response.setRenderParameter("empInfo", value);

 }

2.3 Client-Side IPC  :

There are 2 APIs for client side IPC.

Event generation (call from portlet A):

Liferay.fire('<eventName>', {
            name : value 
});

e.g.
Liferay.fire('planTravel', {
            origin : 'pune',
            destination : 'mumbai'
        });

Event Listener ((call from portlet B):

Liferay.on('<eventName>', function(event) {
       
    });

e.g.
Liferay.on('planTravel', function(event) {
        showNews('', event.origin);
        showNews('', event.destination);
    });

3.  Cookies

Other than the IPC mechanism,  There is an easiest way to get the data between portlets on different pages called COOKIES.  

But there are some limitations for cookies  that it will not accept more than 4KB size datas and the biggest limitation is, the 20 cookies per server limit, and so it is not a good idea to use a different cookie for each variable that has to be saved

Portlet 1    :

To Set the Cookies through jQuery :

<script src="/html/js/jquery/cookie.js" type="text/javascript" > </script>

function setCookie(docURL) {

jQuery.cookie("cookieParam",docURL);

}

To Set the Cookies through java / jsp:

HttpServletResponse response = PortalUtil.getHttpServletResponse(

                                    actionResponse);

Cookie cookieParam = new Cookie("cookieParam ", password);

response.addCookie(cookieParam);

Portlet 2:

To get the Cookies through jQuery :

jQuery.cookie("cookieParam ");

To get the Cookie through java/ jsp :

String sessionid = "";

Cookie[] cookies = request.getCookies();

    if (cookies != null) {

      for (int i = 0; i < cookies.length; i++) {

        if (cookies[i].getName().equals("cookieParam ")) {

          sessionid = cookies[i].getValue();

          break;

        }

      }

    }