Search This Blog


Thursday, March 21, 2013

JEE7: Where we are now, Glassfish v4 and JEE7 roadmap.

GlassFish 4.0 is intended to be the next major release in Project GlassFish which will be in Q2 2013.This release will implement the Java EE 7 specifications which will be released also at Q2 of 2013 as well.

Glassfish v4 is now under testing, project FishCAT maintain this by the contribution of all JCP members, JUGs, and individual for delivering the most stable and functional reference implementation for JEE7 specs.

FishCAT is a GlassFish Community Acceptance Testing program. The main goal of this program is to provide an opportunity to the community to significantly influence the quality of GlassFish as well as to get early feedback on stability and usability through testing early builds.

The release is being designed with primary focus on the following features:

  1. Higher Productivity.
  2. HTML5 Support.

JEE 7 Specification Status

Specification Status Links
Java EE 7 Platform JSR 342 Public Review listproject
Concurrency Utilities for Java EE (JSR 236) Proposed Final Draft listprojectjavadocs
Java Persistence API 2.1 (JSR 338) Proposed Final Draft listprojectjavadocs
Java API for RESTful Web Services 2.0 (JSR 339) Proposed Final Draft
Servlets 3.1 (JSR 340) Public Review 
Expression Language 3.0 (JSR 341) Public Review
Java Message Service 2.0 (JSR 343) Proposed Final Draft
JavaServer Faces 2.2 (JSR 344) Public Review
Enterprise JavaBeans 3.2 (JSR 345) Public Review
Context & Dependency Injection 1.1 (JSR 346) Public Review
Bean Validation 1.1 (JSR 349) Public Review
Batch Applications for the Java Platform (JSR 352) Proposed Final Draft
Java API for JSON Processing (JSR 353) Proposed Final Draft
Java API for WebSocket (JSR 356) Public Review
Java EE Connector Architecture 1.7 (A MR of JSR 322) Maintenance Review listprojectjavadocs
Interceptors 1.2 (A MR of JSR 318) Maintenance Review listprojectjavadocs

For more visit the following links :

  1. Glashfish v4 roadmap.
  2. FishCAT project.

Tuesday, March 19, 2013

JDK7: Explore NIO.2 watch service API & file change notification

Watching objects for file changes and events using thread safe Watch Service API.


JSR 203 is a new java I/O milestone, and the most powerful API ever since the JDK first release, which streamlines all java 7 I/O developments, also it makes I/O applications development easy and powerful more than ever.

The watch service API introduced in java 7 NIO.2 JSR 203 as thread safe service (which) is capable of watching any object for changes and pushes back these changes for you as event notifications. Watched objects should implement java.nio.file.Watchable interface which is the key interface in this API. All the API classes reside in the "java.nio.file" package.

This API is a low level API, which can be used by as it is or you can build your own customized solution that fulfills your requirements. By default it uses the underlying file system features and functionalities to watch registered file system for modification or changes. It allows you to register file, directory or directories to be monitored for different kinds of notification events that you interested in during the registration process.

When one or more of registered events are detected by the watch service, it passes the detected events notifications to the process that responsible for handling the registration process through a separate thread or pool of threads.

Let's clear things up by an example; when you open a file in a text editor like (jEdit, Notepad++, etc.) and if the file is modified by external process outside the editor, the editor will pop up a message box indicating that the file has changed outside the editor and asks you whether to reload the file content because it was modified as shown in (Figure 1). This means that the editor has detected a file change through a watch service, and this service reports back (it) accordingly to the text editor. This is known as "file change notifications" mechanisms. But starting from JDK 7 NIO.2 this service is available through a Watch Service API.

Figure 1: Notepad++ file change notification.

Now as Java 7 introduced the Watch Service API, you no longer need to poll, use in-house solution or external libraries for file system changes. You don't need to implement a separate thread agent the keep track of all contents of the watched directory; to see if anything important has happened.

Regardless the platform (Mac OS X, Linux, UNIX, Solaris or Windows) your application is running on, you have the guarantee that the underlying OS and file system provides the required functionalities that allows your application to receive notifications that has happened on file system as changes.

The Watching Service API Classes:

The java.nio.file.WatchService interface is the starting point combined with three main classes java.nio.file.Watchable, java.nio.file.WatchEvent.Kind<T> and java.nio.file.WatchEvent.Modifier for developing watching capable application. There are multiple implementations for different file systems and platforms. Let's define the functionality of each class as the following:

  1. Watchable Object: Any object is qualified to be watchable if it implements the java.nio.file.Watchable interface.

  2. Event types: Those are the events that you are interested to keep track of their changes, and it is represented by java.nio.file.StandardWatchEventKinds. This class implements the java.nio.file.WatchEvent.Kind interface. The available events are create (WatchEvent.Kind<Path> ENTRY_CREATE), delete (WatchEvent.Kind<Path> ENTRY_DELETE), modify (WatchEvent.Kind<Path> ENTRY_MODIFY), and overflow (WatchEvent.Kind<Object> OVERFLOW).

  3. Registration modifier: This changes the default registration behavior with the Watch Service API. As for now there are no modifiers introduced in NIO.2, it will be implemented in the future releases maybe JDK 8.

  4. Watching service: This is the Watcher that watches the changes done on the file system. And represented by the java.nio.file.WatchService. The created instance from the java.nio.file. FileSystem class runs in the background watching the registered object.

java.nio.file.Watchable interface defines two register methods to register the object with a java.nio.file.WatchService that returns a java.nio.file.WatchKey to represent the registration relationship token between the registered object with a java.nio.file.WatchService. Also an object may be registered with more than one watch service.

The first register method signature is (WatchKey register (WatchService watcher, WatchEvent.Kind<?>[] events, WatchEvent.Modifier... modifiers) throws IOException;), it receives three arguments the first is the watcher(WatchService) object that is created from the java.nio.file. FileSystem implementation and it is responsible for watching the registered objects for changes and events.

The second Argument is the events (java.nio.file.WatchEvent.Kind<T>) array that you need to watch registered object for like create, add, delete and modify events. The last argument is modifiers (java.nio.file.WatchEvent.Modifier). If any, these modifiers determine how the objects are to be registered with watching service.

The second register method signature is (WatchKey register (WatchService watcher, WatchEvent.Kind<?>[] events) throws IOException;) which receives the first two arguments of the first method without modifiers, and I will use this method in our example.

The will known implementation of the java.nio.file.Watchable interface in NIO.2 is the java.nio.file.Path class and it implements the register methods as we will see (it) in the example below.

Get ready, Pre-requisites:

  1. Download and install Java Development Kit version 7 for your favorite Operating System, download it from here.
  2. Netbeans 7.2+ IDE because it supports JDK 7 (Java SE, EE or version All). And could be downloaded from here.
    1. The lightest one for our case is SE version, download and Install it.

How to implement it:

Now as you have considerable knowledge about Watching Service API so far, so after the long theoretical explanation above, let's do the most interesting part, develop the watching application. This application will watch the create, delete, and modify events for the path "D:\My Documents\My Examples\NetBeans\7.2\WatchableDirectory\src\WatchedFolder" (Or any folder of your choice) and reports the type of event and the file where it occurred. The implementation of any watch application is accomplished through a set of nine steps.

In code Listing 1, all the main steps for developing any watch application are numbered in sequence, and the working mechanism explained in how it works section.

For purposes of testing, try manually to add, delete, or modify a file or directory under this path. Keep in mind that only one level down is monitored (only the "D:\My Documents\My Examples\NetBeans\7.2\WatchableDirectory\src\WatchedFolder" directory), not the entire directory tree under the "D:\My Documents\My Examples\NetBeans\7.2\WatchableDirectory\src\WatchedFolder" directory.

Implementation steps:

  1. Create a new Netbeans project(Ctrl + Shift + N) of type Application project from java category, press next.
  2. In Project name text box name your project "WatchableDirectory", tick the Create main class check box and enter the following "", your setup should look like the following figure (Figure 2).
    Figure 2: Setting up the application
  3. Hit finish button and your IDE should open as the following figure (Figure 3):

    Figure 3: Created Project.
  4. The following is the full application, select all (Ctrl + A) code inside the already opened class "WatchDirectory" and delete it, then copy and paste the below code in the following list (Listing 1) as it is:

    Listing 1: The Watching Service implementation.
  5. Clean and build the project (Shift + F11) to check that everything is okay, you should see in the output console "BUILD SUCCESSFUL".

Testing the application:

Now we will go through steps for the testing of the application to see the main function of the developed application:

  1. Right click on Source Packages under "WatchableDirectory" project, select New àOther…, under Categories select other and from File Type select Folder, click next, in the Folder Name write "WatchedFolder", and then click finish. This folder we will use for watching its event notifications. The final result should look like the following figure (Figure 4).
    Figure 4: Created "WatchedFolder"

    Note: if you didn't create the folder and tries to run the application you will get the following exception " java.nio.file.NoSuchFileException: D:\My Documents\My Examples\NetBeans\7.2\WatchableDirectory\src\WatchedFolder".

  2. Right click on "WatchableDirectory" project, Run.
  3. Navigate to your created folder "WatchedFolder" and do the following steps and monitor Netbeans output console:
    1. Create new folder "New Folder", you will see "ENTRY_CREATE -> New folder".
    2. Rename the folder to "NIO2-WS API"; you will see "ENTRY_DELETE -> New folder", "ENTRY_CREATE -> NIO2-WS API" Successively.
    3. Create new text document, you will see "ENTRY_CREATE -> New Text Document.txt".
    4. Open the text file in notepad (or any of your favorite text editor), type in the file the following "I am using Java 7 NIO2 WS API."; you will see "ENTRY_MODIFY -> New Text Document.txt".
    5. The final result in the console should look like the following figure (Figure 5).
      Figure 5: "WatchedFolder" notifications monitoring output.
  4. Click stop to stop the application.

After successful testing of the application, when you run this code on Mac, Linux, UNIX, Solaris, or any other OS as I did, it should work like charm, and you will get the same results.

How it works:

For developing any watching capable application, we should first create watch service object, and we accomplish this by calling "FileSystems.getDefault().newWatchService()" as in Listing 1 (Step 1).

This is a resource that should be closed after usage. in code I wrapped it by JDK 7 try() resource (Step 9) feature which takes care of closing any I/O resource that implements java.lang.AutoCloseable interface, therefore you don't have to care about closing any resource because the JVM will take care of that for you.

Now, we have the watch service we need to register the java.nio.file.Path "D:\My Documents\My Examples\NetBeans\7.2\WatchableDirectory\src\WatchedFolder " for create, delete and modify events. Since the Path class implements the Watchable interface so it provides register() method to be used for registration process with watch service, as in Listing 1 (Step 2)

After successful registration, we need to wait for incoming events to process them. The watch service is responsible for signaling any notifications done on the registered object. Then these events are placed in a watcher's queue from where we can retrieve events. We require an infinite loop to accomplish this by using for (;;) {}, or while (true) {} as in Listing 1 (Step 3).

In Listing 1 (Step 4) we get the queued watch key by calling one of the following methods (all of them retrieve the key and remove it from the watcher's service queue):

  1. poll(): If no key is available, it returns immediately a null value.
  2. poll(long, TimeUnit): If no key is available, it waits the specified time and tries again. If still no key is available, then it returns null. The time period is indicated as a long number, while the TimeUnit argument determines whether the specified time is minutes, seconds, milliseconds, or some other unit of time.
  3. take():If no key is available, it waits until a key is queued or the infinite loop is stopped for any of several different reasons.

In our case we use take() method, bear in mind that the key has state that may be one of the following; When the key is first created its status is Ready which means that the key is ready for accepting events.

The second state is Signaled and it means that the key has queued events and they are available to be retrieved by one of poll() or take() methods, and after all events retrieval the key should be reset to return back to its ready state by calling key reset() method as in Listing 1 (Step 8). It returns true if the watch key is valid and has been reset, and false if the watch key could not be reset because it is no longer valid.

The key enters the Invalid state if the folder is not accessible anymore, deleted, watch service closed, or key cancel() method called explicitly. We can check this state by using key isValid() which returns Boolean value indicating the key validity.

In Listing 1 (Step 5) we need to retrieve pending events for a key by calling the key.pollEvents() which returns a list of pending events of type WatchEvent<T>,[where T ] represents an event (or repeated events) for an object that is registered with a watch service.

After we poll all events, we need to get the kind of each event (create, modify, delete)along with its count. This could be done via the WatchEvent.kind() method, which returns the event type as a Kind<T> object as in Listing 1 (Step 6). If you ignore the registered event types, it is possible to receive an OVERFLOW event. This kind of event can be ignored or handled. It is a special event to indicate that events may have been lost or discarded. This event is not needed to be registered for notification as it is used by underlying API.

After getting the event type, get the associated folder or file to process it by getting the event context (the file name is stored as the context of the event). After getting the event type, the event context (the file name is stored as the context of the event) should be used to retrieve the event associated file or folder for processing. Then we can implement our business logic. This is accomplished by calling method WatchEvent.context() as in Listing 1 (Step 7).

Finally We should reset the key and return it to the ready state to receive other events, till we stop our application or the key becomes invalid, and this is done by calling reset() method as described before. And if the key was invalid the infinite loop should be broken; as there is no reason to stay in the infinite loop, Listing 1 (Step 8).

If you forget or fail to call the reset() method, the key will not receive any further events!

Even more:

Let's wrap:

Here you have explored a great facility of NIO.2, the Watch Service API. You learned how to watch a directory for events such as create, delete, and modify. After an overview of this API and an introductory application, you saw how to we implemented the application in nine steps, provided with the test scenario and finally explaining the working mechanism.

Where is the best use of this API? You can combine this API with NIO.2 walks (java.nio.file.FileVisitor API) to watch a directory tree (all directories under the parent directory). Also you can watch video camera surveillance for its input (row image) and process it. These examples were simply meant to stimulate your curiosity to explore further the exciting world of this API. Since it is very versatile, it can be applied in many other scenarios. For example, you might use it to update a file listing in a GUI display or to detect the modification of configuration files that could then be reloaded.

This API is a thread safe, and the watch service can be used to register many watchable objects simultaneously. Often, the file system of the Most operating system implements his own file notification mechanism, and the watch service API makes use of it. But, if there is lack of this implementation, watch service API will poll the file system for event notification.

Finally it is part of the JDK 7. It means that it has a great support, enhancement and improvements in future JDK releases. Earlier you had to use external library for each operating system to support your application, while watch service API is a portable solution.

Project source code:

The final project source code could be downloaded from here

Friday, March 15, 2013

SOA: Oracle Architect Club Egypt - epayment bulk bill system presentation

Being an Oracle Architects Club board member, my responsibility is to define the correct architecture reference for Oracle customers solutions in EMEA, also
  1. Discover vendor-independent reference architectures.
  2. Discuss new forms of architecting solutions.
  3. Share best practices with other IT architects.
  4. Acquire new competences by enlarging your technological scope.

In this presentation we will see how the best Architecture is used to develop the Bulk Bill Payment System, which enables ease of integration between different entities and system to the core service especially bank entities, to facilitate new change of requirements and integration.



Monday, March 11, 2013

Conf: JDC 2013 Conference & Session Report

Java Developer Conference (JDC) Egypt (follow at @egjdc) is organized every year by Egypt JUG. It is the largest java conference covering Middle East & Africa regions. And it is an international 2 days conference; there are many attendees and speakers from different countries.

There were over 600+ attendees, 40 sessions and 25 speakers, from many countries (session agenda), at the first day there was a redhat and JDC keynote, and at the second day a Nokia keynote discussing the Asha platform future, and there was Nokia phones for giveaways, I didn't have anything from this phones ;(.

It was amazing 2 days. It is the first time to spoke here (JDC2013 and hope in JDC2014); I have met all of the speakers and we have exchanged our info. Thanks JDC2013 and EGJUG for the great efforts and awesome organization of the conference.

I was representing MoroccoJUG in this JDC as I am member of this amazing JUG, Thanks Badr ELHOUARI.

Thanks for JCP members, Arun Gupta, Martijn Verburg and LJC JUG especially Mani Sarker for support & material.

Nokia was the exclusive platinum sponsor, with several Gold (Microsoft "for the first time in JDC", redhat, ITS, and ITWORKS), while Oracle was a silver sponsor, and other media sponsors.

The conference session was mainly focusing on Mobile development specially Nokia Asha platform and development "you know platinum sponsor ;)" and Android, then performance, optimizations techniques, redhat technologies and JEE7 technologies by Me and Mikeal Keith (Oracle Canada).

The Java Source, web site
Insider News from the Java Team at Oracle!, announce for the session also at the following link.

Session contents:

As I am a JCP member and part of Adotp-a-JSR program, I preferred first to talk about the community great efforts that was done and still in progress developing such amazing platform, and the final stage of all JSRs. Also I have talked to EGJUG leaders that I can take the lead of the JUG to participate in Adotp-a-JSR program.

In my session (one and half hour) " with over 45+ attendees, the power of JSON-P, Websocket APIs & HTML5 a hack session", I have begun my talk with introduction of the JEE7 new JSRs, pruned ones, JSRs that has major releases from 1.0 to 2.0 and the others that has minor updates, with introduction to the main aim of JEE7 features for developers and community, and how it supports the time-to-market by being a productive++ platform, Followed by introduction to Adopt-a-JSR program and how JEE7 development influenced by this transparent program and encourage the attendees to participate in the program.

(See Arun Gupta post "Transparency and Community Participation in Java EE 7")

There was a question here and it was:
Is JEE7 targeting the cloud computing?
Answer was:
JEE7 main aim is the standardization and modularity, and since the cloud computing till now doesn't has a standard way to develop a cloud based applications, we preferred to differ it to JEE8 and beyond.

After that, I have begun the talk by Why Websockets? Question, to make the participation spicier, after some interactions, I have explained HTTP protocol then TCP protocol.

For clarity I have introduced an example with 3 use cases for simple trading ticker using HTTP with calculation of bandwidth overhead,and the same use cases with Websockets, I heard Wooooow from their mouths when they saw that the 665MB per second is reduced to 1.5MB per second for 100,000 users, then I have realized that they understand, at this point I have found that navigation to the next points will be more interesting.

The next points was explaining how JEE7 implements the Websocket specifications with Tyrus API touring (server & client) based on the final specification especially the annotations that was refactored, on the other hand I have explored the HTML5 APIs also. After talking about the data exchange types especially JSON and also how it is supported in JEE7. While I am touring the JSON API with examples there are 3 questions raised here:

  1. Question was:
    While there are many java implementations, so why java is too late introducing such an API?
    Answer was:
    As I have said before Java is seeking for standardization, therefore there is a need to allow all developer to has one standard API to work with JSON via JEE and SE platforms.

  2. Question was:
    We need to create the JSON data manually, while in .Net and other implementations I just passed the object and the API serialize it to JSON output?
    Answer was:
    This feature is addressed in the next release of the JSON API by annotation to bind/serialize the JSON input/output respectively, and it will work like its peer JAXB one that serialization and binding the XML.

  3. Question was:
    What if, I have another convenient/fast parser to use and the container supports the JSON-P API only?
    Answer was:
    Indeed you can use your parser as there is no limitation on the usage from JEE7 container, but to be modular the API support the SPI implementation, and also you can configure the API when creating the parsers and generators through its factories.

The next point was how to unit test the Websocket alongside JSON-P API with code examples (and the tests shows a GREEN BARs thanks God).

Finally we went through the final project RTRC (Real Time Runners Champion), that demonstrate the Websockets in action as backend, while the HTML5 as frontend client, and data exchanged was in JSON format.

The project consists of Login screen connected to backend Websocket, and when successful authentication I have registered the runner in the champion, then in his/her tracer screen I have used Geolocation to get runner longitude, latitude and its timestamp and send these information to the server with his/her name to podcasts to other runners in real time and tag all location on runner map to see the progress of all other runners, with function that calculate the distance from current runner location from finish point location.

It was a maven based application, also I have used Netbeans early access version that support JEE7 and Websocket API.

Download project source code from here.

Recorded Material:
The session was recorded and once it is uploaded I will update with podcast location.


Some comments:

Comments link 1

Comments link 2

Some pictures from event:

Many thanks to Ahmed Ali, Ahmed hashem and the rest of the JUG amazing team, for taking care of every detail and providing a high level of support.

Special Thanks to Graphics & social media Guys for such a great advertising.

Friday, March 1, 2013

Browser: Microsoft IE10 is the first release supporting HTML5 Websockets API.

In my previous post "Microsoft has released IE 10 for windows 7", I have mentioned that this version comes with extensive support for HTML5 APIs, provided with a download link.

Among HTML5 APIs I was looking forward for the support of HTML5 Websocket API.

As I am a JCP member, working on Adopt-A-JSR program for testing the reference implementation (Tyrus) of Java API for WebSocket 1.0 (JSR 356), beside enhancing and validating the specification, that will be part of the next release of JEE7 (Java Enterprise Edition 7) which also includes a lot of server supports for HTML5 APIs as well as the cloud based applications.

I have tested my developed application on IE10 for communication with my endpoint deployed on Glassfish v4_b78 (The reference implementation for JEE7 specifications umbrella), and the result was successful, as the following Figure 1.

Figure 1: The testing results on IE10.

This means that IE10 is the first Microsoft browser version that supersedes previous versions 9- for HTML5 Websocket support.

Who Supports WebSockets Today?

The following table provides a brief summary of the support for WebSockets that most popular browsers provide at present.

Table 1 Browser Support for WebSockets


WebSockets Support

Internet Explorer

WebSockets is supported now in Internet Explorer 10. Metro applications written using JavaScript and HTML5 will support WebSockets as well.


WebSockets are supported starting with version 6 of the browser released in mid-2011. Some very early support was offered in version 4 and then dropped in version 5.


Support for WebSockets has been removed in version 11.


WebSockets are supported starting with version 14, which was released in September 2011.


Supports an earlier version of the WebSocket Protocol.

With the exception of Firefox, you can programmatically check for WebSockets support by looking at the window.WebSocket object.For Firefox, you should currently check the MozWebSocket object. It should be noted that most HTML5-related capabilities can be checked in browsers by means of a specialized library such as Modernizr (

In particular, here’s the JavaScript code you need to write if you linked the Modernizr library to your page:

Now almost we have the chance to run all of HTML5 websocket based client's applications, on the majority of popular vendors browser.