Tuesday, 23 October 2012

JavaEE Revisits Design Patterns: Decorator

This time last year I wrote a series of blog posts on JavaEE implementation of design patterns. Roughly after a year, I realized I missed my favorite pattern, the decorator.

Decorator pattern is basically a way to extend functionality of an object by decorating with other objects which can wrap the target object and add their own behavior to it. If you never used or heard of decorators, I highly recommend reading chapter 3 of Head First Design Patterns.

Pretty much like other patterns mentioned in my posts before, JavaEE has an easy an elegant way to use the decorator pattern. Lets start with a simple stateless session bean.


package com.devchronicles.decorator;

import javax.ejb.Stateless;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;

/**
 *
 * @author murat
 */
@Stateless
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class EventService {
    
    public void startService(){
        System.out.println("do something important here...");
    }
}

To start implementing the decorator pattern, we need an interface so we can bind the decorators and the object to be decorated together.


package com.devchronicles.decorator;

/**
 *
 * @author murat
 */
public interface ServiceInterface {
    public void startService();
}

The interface has the method which the decorators will add functionality on. Next we need some changes on our existing EventService bean to make it decoratable.


package com.devchronicles.decorator;

import javax.ejb.Stateless;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;

/**
 *
 * @author murat
 */
@Stateless
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class EventService implements ServiceInterface{
    
    public void startService(){
        System.out.println("do something important here...");
    }
}


Now we are ready to add as much as decorator we need. All we need to do is to annotate our class, implement the ServiceInterface and to inject our service delegate.


package com.devchronicles.decorator;

import javax.decorator.Decorator;
import javax.decorator.Delegate;
import javax.inject.Inject;

/**
 *
 * @author murat
 */
@Decorator //declares this class as a decorator
public class DecoratorService implements ServiceInterface{ //must implement the service interface
    
    @Inject //inject the service
    @Delegate //and annotate as the delegate
    ServiceInterface service;

    @Override
    public void startService() { //implement the startService method to add functionality
        System.out.println("decorating the existing service!");
        service.startService(); //let the execution chain continue
    } 
}

Several decorators can be using the service interface.


package com.devchronicles.decorator;

import javax.decorator.Decorator;
import javax.decorator.Delegate;
import javax.inject.Inject;

/**
 *
 * @author murat
 */
@Decorator
public class Decorator2Service implements ServiceInterface{
     @Inject
    @Delegate
    ServiceInterface service;

    @Override
    public void startService() {
        System.out.println("decorating the service even further!!!");
        service.startService();
    }
}

Most of the configuration can be done via annotation in JavaEE6. However we still need to add some xml configuration to make decorators work. It might seem disappointing since we already annotated our decorators but still the configuration is pretty simple and needed in order to declare the order of execution. Add the following lines to the empty beans.xml.


<?xml version="1.0" encoding="UTF-8"?>
<beans xmlns="http://java.sun.com/xml/ns/javaee"
       xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
       xsi:schemaLocation="http://java.sun.com/xml/ns/javaee http://java.sun.com/xml/ns/javaee/beans_1_0.xsd">
           <decorators>
               <class>com.devchronicles.decorator.DecoratorService</class>
           <class>com.devchronicles.decorator.Decorator2Service</class>
           </decorators>
</beans>

When the startService method of our EventService is executed, the decorators will decorate the ejb and add their own behavior to the execution.

...

INFO: WEB0671: Loading application [Decorator] at [/Decorator]
INFO: Decorator was successfully deployed in 2,534 milliseconds.
INFO: decorating the existing service!
INFO: decorating the service even further!!!
INFO: do something important here...
...





Monday, 22 October 2012

JavaOne 2012: The Good, The Bad and The Ugly...

Just like last year JavaOne was prior to fleet week and the weather was great. It is always great to visit San Francisco and see some 'regular' JavaOne friends like Van Riper and Yakov Fain.

This was Oracle's third JavaOne and there is no more JavaOne 2.0 posts anymore. So seems like everybody already get used to the new JavaOne.

JavaOne 2012, The Good...
Although my first intentions were pretty negative against Oracle's Sun buyout and the first JavaOne which Oracle organized, it is obvious that Oracle is doing great with Java. They might still lack at understand the community but they are doing ok. Oracle is really committed to development of Java. JavaEE6 is doing great and if JavaEE7 can show a similar fast adoption, it would definitely rock. JavaEE has never been so fast, lightweight, robust and productive so Oracle really succeeded in enterprise.
JavaSE is also doing great. JavaSE8 will be introducing a variety of new concepts to Java programmers, including default methods and lambda. Oracle is really committed to the time plan so they did not hesitate to drop out features which seem to be late. This schedule commitment is good for all vendors and the community so again well done Oracle.
Java on desktop has been dead for long. Honestly I wasn't really expecting a keen support from Oracle but they are also doing good with JavaFX. I really appreciate Oracle for hiring JavaFX professionals such as Stephen Chin and giving them appropriate responsibilities. JavaFX might not be a real -strike back- but it is a good effort and the community is happy to see Oracle's commitment.
Finally it was great to see James Gosling back on the stage for the keynote.

The Bad...
JavaME is dead and finally Oracle seems to accept the fact. The mobile content was very poor. Since the Google-Oracle war on Android is over, it might be wise for Oracle to act as a step-father for Android else next year JavaOne will have no mobile content. Project Jigsaw has been left out from JavaSE8 to catch up the release date but being left to JavaSE9 clearly mean it would be too late. Again it might be wise to adopt OSGi and bundle it with JavaSE8.

and The Ugly...
The conference is getting worse in terms of content. I didn't really see as great sessions as previous years. Lack of former Rock Stars is pretty obvious. Since the Google-Oracle war is over, it would be wise to get some Google content like android and gwt. At worst since Joshua Bloch left Google, he might be back on stage next year.
The venue is getting worse. Kicking out JavaOne from Moscone and spreading the conference into three hotels was a bad idea but it is getting worse with another venue getting involved for sunday keynote. Why not using Moscone for the sunday keynote? Oracle has Moscone South, North and West where Apple and Google only rent Moscone West to perform their annual conferences. Why not sharing venues for at least the sunday keynote than sending hundreds of developers to somewhere else?  I don't really understand why Oracle insists on same dates for Oracle Open World and JavaOne.
If Oracle can not bring the old JavaOne spirit and content back, they may not find many developers to pay +$1500 to attend a conference in the following years. Honestly I wouldn't if I didn't have a session.

Tuesday, 11 September 2012

GWT RPC: The response could not be deserialized only when using Lists

"The response could not be deserialized" is one of the very basic error you may come up with when using GWT-RPC. The reason is usually quite simple but sometimes could be more cryptic.

com.google.gwt.user.client.rpc.SerializationException: The response could not be deserialized, com.google.gwt.user.client.rpc.IncompatibleRemoteServiceException: The response could not be deserialized 

If you google the errors above, you will end up finding answers to most common mistakes done when using GWT-RPC.

The most common error is failing to implement IsSerializable or Serializable interfaces. You may feel like using java both on the server and the client but GWT needs to translate every Java object to its Javascript counterpart. To achieve that when using rpc calls, all objects exposed to this call should be serialized which can only happen if the object has implemented on of those two interfaces. When GWT first came out, it offered its own version of serialization interface, IsSerializable. However, later the the convention was moved to default java Serializable interface. So using either is fine but current convention is using the Serializable interface. Keep in mind all nested objects needs to implement Serializable, not only the root object.

The second common error is the missing default constructor. GWT needs to instantiate your objects using the default constructor which is created by the default by the compiler if you did not add any non default constructor. So if you had add constructor(s) with parameter(s), never ever forget to add an empty default constructor.

Third and most challenging problem is a bit more cryptic because actually the serialization works when the service returns the objects you created, however, only fail when returning a list or arraylist of those objects. The first two solutions does not apply for sure since the object can be serialized when returned directly. The reason of this error is using the wrong version of gwt-servlet.jar in project class path. Google plugin adds this jar when a GWT project is created. However if you convert the project to maven and add get as a maven dependency or manually add any GWT library, you may end up with 2 gwt-servlet.jars in your classpath.

Check the buildpath, dependencies, deployment descriptor, maven dependencies and WEB-INF/lib folder (this is where gwt adds the servlet jar) for any duplicates or any other version then the gwt compiler you are currently using.

Thursday, 16 August 2012

Flash is Officially Dead! R.I.P old friend...

Adobe has recently pulled Flash player from Google Play. Although Adobe already announced they are not going to update flash for mobile last year but as today officially there is no Flash Player available for mobile devices anymore.

This blog used to be called FlexJava few years ago. I was a keen believer of Flash and Flex for the future of the web. Flex could offer easy and rich enterprise app development when compared to JSF or other Java Web UIs. The Flash engine could easily overcome cross browser issues and could even make ie6 work. I used to love flex, code on actionscript and run on flash player. I tought many developers how to write flex.

So what happened? Steve Jobs did not want Flash on iOS. Actually this was his personal war with Adobe but honestly Adobe did everything to prove he is right.

Adobe could never ship the long waited Flash Lite on time!
Adobe was slow to innovate and update the flash player!
Adobe could never overcome the performance issues and battery issues!
Adobe could never update flash player to work seamlessly with touch controls!

Although it was quite late, Adobe managed to release Flash player for Android which just proved Steve Jobs was right! Simply Flash was not for mobile!

Actually it was... Only if Adobe could invest enough resources to improve Flash/Flex/Flash Player. I had chance to chat with several Adobe employees for the last few years and always here the same words... Flash Player is free so we can never make Adobe to invest enough in the player.

Goodbye Flash, goodbye old friend... I hope you rest in peace...

Tuesday, 17 July 2012

After I/O 2012

Starting from registration to giveaways, the I/O madness going far each year. Being sold in 20 mins this year, did not stop google to give away even more stuff. With this pace and expected release of google glass for next year, most probably next year registration will go even more chaotic! So Google, please either stop giving free stuff (I know you won't) or move to Moscone North and have a bigger I/O!

Keynotes of Google I/O is something out of this world. It is more like a rock concert than a tech conference keynote. Extending I/O to three days did not make it less compact. Usually you have at least 2 parallel sessions you want to attend and not much time left for playground and office hours but the best thing with I/O is all sessions are made available online instantly.

So here is the wrap-up from I/O 2012!

Android
Google is well aware of weak points of Android and doing everything to fix it. Unlike Apple who is sure on the perfection of the initial design and only making enhancements on the platform, Google can rapidly change the whole experience. The hardware buttons are gone, the options button is gone, best practices for the UI has changed a lot. Android started with as a highly flexible os and since from ICS, getting nicer and more responsive UI with each update where apple started with sleek UI but not much functionality, now adding the missing parts.
Google addressed 3 major problems of Android and did best to provide a solution.

  • UI experience: With the Jelly bean, UI and animations are much faster and responsive. Chrome brings a well known user experience and a great integration with the desktop counter part. Jelly Bean offers a very smooth and sexy UI very comparable to iOS experience.
  • UI of the Apps: Android apps tend to have problems with UI because of lack of tools and different screens sizes and resolutions. Latest toolkit brings everything an app developer would ever need. Preview and easy fix for all possible screen sizes, easy problem detection with Lint, more capable UI designer, much much better emulator may hopefully help developers to build higher quality apps.
  • OS versions: Although ICS has been released more than 6 months ago, there are very few devices had chance to upgrade. ICS has less then 10% share and most of those devices are pre-bundled with ICS which means nearly zero updates to current devices. This reflects a huge problem for the Android ecosystem. Whatever Google brings to innovate never gets into the devices in our pockets. Google had released the Platform Development Kit for the device manufacturers which would hopefully address this issue.
Glass
Explorer edition is on presage and current product demos show Glass is quite near functional although Google still insists it is early development stage where Microsoft claims Surface to be complete although there are no major technical details. Google Glass can be the next revolution after iPhone. With Google Now, Google Glass will offer location and context aware interaction to your daily life. Glass can be controlled in three different ways, head movements, voice and with its touchpad. Although it is not confirmed there is a rumor on another way of control through a simple ring which would make sense since most people wear rings and a ring can offer iPod click wheel like control. Glass does not offer radio and use wifi for data. Battery life is still something being worked on although with minimal usage it can survive up to a day of usage but if you are planning to hangout while sky diving it may not survive more than few hours. It is powered by Android which would offer an easy adaption for app developers. Developer only Explorer edition will be shipping end of this year so most probably by the time of next I/O we will be experimenting the finished product.


 GWT
The dying rumors are over. It is clear that Google had difficult times after the GWT team dissolved. They even had hard times accepting patches since GWT is heavily used in internal projects. Google stepped back from the governance of GWT and formed a steering committee. The steering committee is a great chance to move forward and it is great to see members like Daniel Kurka who wrote mGWT.
Release candidate of version 2.5 is out and the feature set is unbelievable. Super dev mode, source maps works like magic and the compiler is much better optimized.

Google+
Google Events is smart! It was a great strategy to release it just before the I/O party in which every attendee has at least two android device.

Compute Cloud
Finally limitations of App Engine is over. Google offers cloud computing just like Amazon's EC2. With the Compute Cloud, Google can now offer a full stack of services.

Google Now
Finally the Google Now which is an integrated location and context aware service. Google Now can understand you are at work, about to leave and tell you the traffic to home or can understand you are at the airport and knows your flight from your recent searches so can guide you to your gate and even inform if there is a delay. It is amazing, mush more seamless and integrated to your life than siri.

So I/O is over and it was great,. Just wondering what will the registration be like next year since the expectations of Google Glass freebie is quite high.

Wednesday, 4 July 2012

Making NexusQ Work Outside U.S.

Well actually I was planning to write on io, android and gwt but at last I found a way to run the NexusQ outside U.S. and can't stop posting.

Here is the apk file needed to turn NexusQ into a streaming device rather than a night lamp! Well you will not still watch movies but at least youtube will work and also some of the music.

Enjoy I/O 12 attendees!

Saturday, 7 April 2012

Let's fix Android!

No ecosystem is perfect, neither iOS nor windows. Most of the iOS developers would remember the days iPhones used to lack multitasking and the developers need to implement everything on 'applicationWillTerminate' method. Android also has its own flaws.

Android ecosystem has grown far strong and large. 850.000 devices are activated each day and by end of the year this would be much more than a million. Big ecosystems have bigger problems which is normal (compare pcs to macs). However the success on the phone market did not really achieved by the tablets. There are only a few set of devices supporting the latest os although it has been out months ago and even a newer version is on the way. 

I believe only the ecosystem can solve its problems. Both the users and the developers need to take responsibility! Here is the manifesto lets fix android!!

To Users,
- Do not buy devices not shipped with the latest available version of the Android OS! Vendors promised to bring the latest os to all devices with compatible hardware in 6 months [Google I/O 2011] but they did not. ICS was released months ago but it is still 2-3% of the whole devices. Still 90% of the devices are between 2.0 and 2.3. 
- Do not believe 'upgradable to' promises. I own an LG Optimus 3D which I was told upgradable to 2.3 last may but it is still stuck at 2.2. If it is not shipped with the latest version, simply don't buy! 
- Choose brands who tend to keep their devices up to date. Sony seem to have better reputation so far. Also reference devices (nexus one, nexus s, galaxy nexus, xoom) have a higher chance to get updates.  
- Support developers of the free software with your comments and ratings. Those people give their software for free so don't expect them to hire designers and buy graphic assets. If you have a problem or idea try to contact them. I personally replied every email i had about every complaint or feature request.
- Buy software. Android users tend to spend much less than iOS users. You pay for the device, for the network so pay for good software!

To Developers,
- Just because Google does not control the software you upload to Play, it does not mean you don't need to care quality. Follow best practices and UI guides. At least watch, read and listen free materials. There are great Google I/O talks.
- Don't thread tablets just as big phones. Build custom UI, use custom graphic assets and add new functionality. Android tablets are suffering on nice software. Keep in mind one way or other there will be more android tablets soon and if you can build something good you will shine.
- Don't design on your own and delegate it to a professional if possible. If not, use royalty free graphics.
- Use AsyncTask everywhere possible, don't lock the UI thread and make your software not responding.
- Keep the view hierarchy short, try not to use LinearLayouts.
- Explicitly use hardware acceleration.

... and finally Google,
- Everyone was mad with how apple deal their app store but it may be good to have a little more control on the content.
- Again it seemed great to have a free os but seems like vendors fail to keep their devices up to date. Just do something, anything but encourage and lead the to update their device's OS.
- Android grow so big that it took over Google I/O. Either have a seperate Android conference or just extend Google I/O and bring more people in.

Saturday, 31 March 2012

JavaEE Revisits Design Patterns: Aspects (Interceptor)

I have written some blogs on aspects years ago. AspectJ and Spring Aspects have served well for long years. However they may not be the first choice when it comes to JavaEE world. I have written several posts on how JavaEE implements several design patterns (singleton, dependency injection, factory, observer, asyncronous) and aspects is not an exception.

Interceptors are very easy to implement in JavaEE without any xml configuration. Lets go back to our example given in the previous posts and start with adding a new plain class. Since we already used logging as an example for the observer post, lets assume now we need to implement a security mechanism on our existing service.


package com.devchronicles.observer;


import javax.interceptor.AroundInvoke;
import javax.interceptor.InvocationContext;


/**
 *
 * @author murat
 */
public class SecurityInterceptor {
    
    @AroundInvoke
    public Object doSecurityCheck(InvocationContext context) throws Exception{
        System.out.println(context.getMethod().getName());
        
        return context.proceed();
    }
}


As mentioned before the class is a plain java class and does not implement or extend any other class. Here the @AroundInvoke annotation does the magic. The methods marked with this annotation need to return an Object and get a InvocationContext parameter. InvocationContext gives access to method and parameter info and values as well as ability to change them. In this example we simply get the method name. Another important point is to call context.proceed() to continue execution process.

To put our interceptor in action we need to add an annotation to our target classes which is the EventService bean from the previous posts.


package com.devchronicles.observer;


import javax.ejb.Stateless;
import javax.ejb.TransactionAttribute;
import javax.ejb.TransactionAttributeType;
import javax.enterprise.event.Event;
import javax.inject.Inject;
import javax.interceptor.Interceptors;


/**
 *
 * @author murat
 */
@Interceptors(SecurityInterceptor.class)
@Stateless
@TransactionAttribute(TransactionAttributeType.REQUIRED)
public class EventService {
    @Inject
    private String message;
    
    @Inject 
    Event<String> event;
    
    public void startService(){
        System.out.println("start service call "+message);
        event.fire("this is my "+message);
        System.out.println("done...");
    }
}

Don't worry about the grey and specially the lighter grey parts which comes from the previous posts. The @Interceptor annotation is the only code we need to add to make our existing class a target for our interceptor and there is no other configuration need to be done!


Monday, 19 March 2012

Android merges back to Linux

Finally the day come that Android merges back to Linux repositories. Android Kernel was forked from Linux but failed to merge back due to disagreement between developers from both projects. With the latest news from lwn.net and kernelnewbies.org it has been stated that various Android subsystems and features have already been merged, and more will follow in the future.

Android has taken linux somewhere no linux fan could ever imagine, today even Microsoft is building applications for Android which actually made them built applications for linux. Avery good news for both parties for the future of both projects.

Sunday, 11 March 2012

Session Sharing between Java Web Applications

We had been asked to share sessions between different war files several times on different projects. This requests vary from just asking our opinion to trying to persuade us to do it by citing vendor documentations. 

Those who had watched Star Wars before, would probably remember Darth Sidious's famous saying:
 Dark side of the force is the pathway to many abilities, some considered to be... unnatural.
However, only Siths tend to use the dark side. Jedis instead follow the Jedi code. Back to our topic, if we would need a code for the light side on the Java world, that should be the Java Specs by the JCP. Although most vendor implementations would let you share sessions by their custom settings.
Sharing sessions between web applications will override the following JSRs, thus make your application not compatible with Java Standarts. 

Servlet Speciation - "SRV.7.3 Session Scope HttpSession objects must be scoped at the application (or servlet context) level. The underlying mechanism, such as the cookie used to establish the session, can be the same for different contexts, but the object referenced, including the attributes in that object, must never be shared between contexts by the container."  

Servlet Speciation - "SRV.9.2 Relationship to ServletContext 
The servlet container must enforce a one to one correspondence between a web application and a ServletContext. A ServletContext object provides a servlet with its view of the application.
In order to share data across web applications you'll need to implement your own scheme. If it's a small amount of data, you could store it in a cookie that either web application could retrieve. If it's a large amount of data, you could store it in a database, then set a token in a cookie to identify the client and retrieve the data."


JavaEE Specification - Removal of class loader barriers to share session data will impede each component to define its security requirements through a deployment descriptor.  Components will be accessible from each other disregarding deployment descriptors (EE3.6 EE3.3).

Sharing sessions between web application would violate those items both in Servlet and JavaEE specifications. However, there are different ways to pass data between web applications without breaking the rules.

First and easiest solution would be cookies. It is possible to store simple and small data on the client side using cookies.  The session cookies can be encrypted and can store small amount of textual data. Session cookies can be used to store non-sensitive session information, they can be share between a group of applications using context paths.

If the data needed to pass is more complex and sensitive there are third party solutions from different vendors or MemCached.  These technologies enables session sharing and management across different web applications, domains and heterogeneous application servers; They are typically distributed for scalability, availability, reliability and performance to in-memory session management and storage; They support all the mainstream application servers such as Oracle WebLogic Server, IBM WebSphere, Tomcat., Oracle WebLogic Portal, etc. 

Whatever solution you choose to implement, always try to be compatible with Java specs although some vendors would give you opportunity not to do so. Keep in mind coupling with a vendor by breaking the rules would lead you to a different path which might considered to be... unnatural. 

Thursday, 23 February 2012

Adobe abandons Flex

Adobe recently published the roadmap of Flex which they had donated to Apache. Since Flex was already an open sourced project, that was a logical step. However, the recent document showed Adobe has already abandoned the Apache's Flex. Here is an interesting part from the document.
Flash Player 11.2 and Adobe AIR 3.2, which are anticipated to ship in the first quarter of 2012, will be tested with applications built using Adobe Flex 4.6. Adobe will test future releases of Flash Player and AIR against the Adobe Flex 4.6 SDK and maintain backwards compatibility for five years.
Although Adobe tried to make it look friendly with the "backwards compability" keyword, this statement just shows Adobe is not planning to integrate anything done on Apache to Adobe's Flash Runtime. Actually they also make the more clear.
In the past, features were added to Flash Player and AIR specifically to support the needs of Flex applications. Going forward, features will be added to the runtimes to support Adobe’s vision for the Flash Platform. The Apache Flex Project may choose to take advantage of those features; however, new features will not be added to the runtimes specifically to support the Apache project’s efforts.
I am not sure if that is a joke but Flex was widely accepted just because of Flash Runtime and if Adobe is not going to support Apache's Flex on their runtime, expecting them to build a Flash clone, they are just wasting Apache's time and resources.

Adobe also announced they are abandoning the Flash Catalist which was planned to be an important tool for the new UI Architecture called Spark. They had spent years to built a lightweight UI framework optimized for mobile from scratch while abandoning the long waited Flash Mobile. They blamed Steve Jobs for not letting Flash in iPhone but the moment Flash player appeared on Android everyone realized it was slow, not good to use on touch screen and draining the battery just like Steve Jobs once said. Instead of making investment Adobe just pulled the plug of Flash on mobile saying they would invest those resources into Flex and Air.

It is quite clear, Flash's future is not clouded and more... it just doesn't have a future...

Quoting Vader, Adobe I find your lack of faith disturbing! Sadly I can't just force grip to choke you.

Sunday, 1 January 2012

Moving from 2011 to 2012, seriously!

I have done several new year posts (for 2008 and 2009) in the past. Reading them today once again made me remember the saying "be careful about predicting when future is involved".

Both posts clearly show I was a keen believer of Rich Client Platforms especially Adobe's Flex. The rise of iPhone which is followed by iPad and other mobile devices crippled the plugin based web platforms. Adobe who should already been working on mobile version on Flash, was never accepted on iOS but also failed to deliver a reliable Flash Plugin on other platforms. Finally this year Adobe discontinued mobile Flash in favor of focusing on Air.

The fall of the plugin based platforms let HTML5 get even more attention. Even Microsoft who still does not have a real HTML5 supported browser, killed Silverlight and announced HTML5 would be the main development platform for Windows 8 (aka Metro apps).

Despite all the trends there are still a lot of IE6 and 7 (also 8!) users which would make html5 hardly be used in real world projects. However many new web frameworks make use of available features and try to mimic the not supported ones. Still HTML5 might be too bleeding edge unless your project only aim to run on mobile since most of the mobile browsers do fully support most of the HTML5 features.

Android despite all patent issues, still on the rise. With the latest release of version 4.0, the ice cream sandwich, finally both phones and the tablets started running on the same operating system. However the version fragmentation became more visible. Even most of the phones still on sale are still based on version 2.2 or 2.3. Although many vendors announced upgrade plans, even most popular devices failed to updating 2.3. Besides the OS fragmentation, Android devices still lack nice designs and good build quality. Currently the only up to date device on the market is Galaxy Nexus and there are several nice designs such as Sony Experia Arc and Sensation XE/XL but still lacking updated os version.

Meanwhile Apple is still having their glory days. Although there were no major updates, iPhone 4s became a huge sales success. Everyone is waiting for the iPad3 which is rumored to have retina display. Although Apple is rumored to stop selling Mac Pros, Macbooks are getting popular than ever and if you ever had worked on one you would probably know why (if not, please try one! seriously).

Social media and apps are hot. Facebook and Twitter might have already taken the lead but apps like foursquare showed there might be room for more. So Google did not hesitate to jump in with Google+ which became the fastest growing network ever.  

So here are some keywords for 2012:

  • Don't count on plugin based platforms (Flash, Silverlight and even JavaFX). At least for the next few years the web will be HTML...
  • Learn Javascript! Although many frameworks might help you to generate js, still it is best to know the real thing.
  • Invest in mobile! Forget about JavaME (seriously), even if you are lazy to learn Objective-C, you can easily start coding on Android.
  • If you are an existing Flex/Actionscript developer, try out Flex for mobile! It is currently the easiest and most reliable way to build apps on both android and ios from one source.
  • If you are not then no need to spend time on Flex. Instead learn coding on native or html5. Take a look at PhoneGap and SenchaTouch.
  • NoSQL is hot. Give it a try!
  • JavaEE6 became even more lightweight and exciting with WebProfile which made using Spring obsolete. You can use either TomEE or Glassfish which boots up just as fast as plain Tomcat.
  • Invest in HTML5! Instead of starting from scratch try HTML5 Boilerplate and Bootstrap from Twitter.
  • If you are keen on HTML5 on real projects, take a look at Modernizr.
  • Unless you are a CSS master, try out {less} which might become a good HTML5 companion.
  • CoffeeScript is getting popular. Again unless you are a Javascript Ninja, it is worth to try.
  • Scala seems to be a good choice for next language to learn, well even Joshua Bloch says so...
  • If you are brave enough to stay on the bleeding edge Play! is a great alternative web framework which also has built in support for scala.
  • If you are looking for a solid, proven web framework while still able to use HTML5 features, GWT would be a wise choice. 
  • Dart is new but it is worth to follow. Even if the Dart VM fails to be widely adopted it still has the option to cross compile to Javascript and the Google guys are experienced in doing that!