Introduction to Java EE 6 Wednesday, Jan 6 2010 

Download Here ———–> java_ee6_tutorial

Advertisements

What’s New with Java EE 6 Friday, Dec 11 2009 

Download PDF file here… About Java EE 6

AJAX with Java Platform Tuesday, Dec 8 2009 

Asynchronous JavaScript Technology and XML (Ajax) With the Java Platform

By Greg Murray, June 9, 2005; updated October 2006

Anyone who has used Flickr, GMail, Google Suggest, or Google Maps will realize that a new breed of dynamic web applications is emerging. These applications look and act very similar to traditional desktop applications without relying on plug-ins or browser-specific features. Web applications have traditionally been a set of HTML pages that must be reloaded to change any portion of the content. Technologies such as JavaScript programming language and cascading style sheets (CSS) have matured to the point where they can be used effectively to create very dynamic web applications that will work on all of the major browsers. This article will detail several techniques that you can use today to enable your web applications to be more rich and interactive like desktop applications.

Introducing Asynchronous JavaScript Technology and XML (Ajax)

Using JavaScript technology, an HTML page can asynchronously make calls to the server from which it was loaded and fetch content that may be formatted as XML documents, HTML content, plain text, or JavaScript Object Notation (JSON). The JavaScript technology may then use the content to update or modify the Document Object Model (DOM) of the HTML page. The term Asynchronous JavaScript Technology and XML (Ajax) has emerged recently to describe this interaction model.

Ajax is not new. (more…)

Integrating Java and Erlang Wednesday, Apr 30 2008 

By Dennis Byrne

January 2008

Discuss this Article

Building scalable, distributed and reliable systems is trivial in Erlang. This can be a hard pill to swallow for many enterprise developers. Erlang is a dynamically typed functional language and Java is a statically typed object-oriented language. Erlang is an agitator to traditional enterprise development because it excels so well at concurrency, uptimes of five nines or more, and “hot deployment” of code. But there are valid reasons for why someone may not want to dive in head first. How many CIOs want to lose their investments in Java? Who wants to leave behind all the great libraries produced by the Java community?

This article is for a lot of people: language enthusiasts, software fashion victims, or anyone who wants to create serious business value bridging Erlang with Java. We’ll start with an introductory tour of Erlang by building a simple client server application. Following this we’ll reverse engineer the application in pure Java using Jinterface, an open source Java library distributed with Ericsson’s Open Telecom Platform. Then we’ll wrap things up with a few words about hybrid systems development. Download and install Erlang and Java if you wish to try this at home.

Concurrent Programming with a Simple Client Server Module

Erlang is a freak of nature; it has concurrency in its DNA. Concurrency is a native construct, all the way from the syntax down to guts of the Erlang virtual machine. This is fundamentally different than the traditional approaches to concurrency: expensive third party products, complex APIs for distribution, and java.lang.Thread. Let’s begin our overview of Erlang with a little concurrent programming.

In an effort to stay focused on the core concepts we will avoid the deep end for now and keep it simple … by calculating the sum of two numbers. The logic needed to perform addition will be contained within an Erlang module and exposed via an Erlang process. Afterwards we’ll consume this service from a client process. With a little stretch of the imagination I’m sure most of you can envision the possibilities, like distributing a financial algorithm across 32 cores – or 32 cores on 32 machines.

An Erlang module consists of annotations and functions. For the purposes of this article, think of an Erlang module as a Java package. Our module starts with two annotations in a single file named mathserver.erl.

-module(mathserver).

-export([start/0, add/2]).

The first annotation declares the module name. The second annotation declares which functions are exported by the module; this is similar to using the keyword “public” in Java. The exported functions of this module are start and add, which we’ll implement shortly. Did you notice that each line ends with a period? Functions and annotations in Erlang are terminated with a period, not a semicolon. Now let’s create our first function, the server entry point for the mathserver module.

start() ->

Pid = spawn(fun() -> loop() end),

register(mathserver, Pid).

The start function creates an Erlang process with one of the Erlang concurrency primitives, the spawn function. The term “process” can be confusing to newcomers, who often (understandably) misinterpret it as an operating system process. An Erlang process is more like a Java Thread, only extremely lightweight. Feel free to spawn thousands if you need to. Each process has a private heap. This design insures no shared state among processes. Processes are therefore easily parallelized and messages are passed by value, as opposed to being passed by reference. All intra-process communication in Erlang is asynchronous and all processes run in parallel. Read a little about the Actor Model for a more conceptual perspective on Erlang processes.

The argument passed to the spawn function, fun() -> loop () end , is an anonymous function. It represents the behavior of the to-be-spawned process. This is similar to a closure in Javascript, or a lambda in Ruby; in Erlang, it is called a fun. This fun wraps a named function, called loop, which we’ll get to later.

Each process has a process identifier, or pid. The spawn function returns the pid of the spawned process. A pid can be conceptually thought of as a mailing address for a process. It is the means by which messages are passed to each private mailbox of a process. There is a one to one to one relationship between a pid, process and mailbox.

The start function ends using the built-in register function to register the pid as “mathserver”. Once registered, we can forget about tracking the pid value and simply address the spawned process via this alias constant.

Erlang is more restrictive than Java when it comes to variables. For example, did you notice the pid variable starts with a capital letter? This is true for all variables in Erlang. Erlang also enforces “no side effects” with single assignment, so the value bound to the Pid variable is constant. In Java this is a choice made by the developer, using the keyword final.

Remember the anonymous function we passed to spawn? That function wrapped the loop function, which represents the actual behavior of the spawned process.

loop() ->

receive

{From, {add, First, Second}} ->

From ! {mathserver, First + Second},

loop()

end.

The loop function uses another one of the Erlang concurrency primitives, the receive statement. When a message is sent to the mailbox of an Erlang process, it is pulled out of the mailbox and matched against each pattern in the receive block. Like a lot of other functional programming languages Erlang makes heavy use of pattern matching. Feel free to temporarily think of receive statements as switch blocks, and receive patterns as case labels (Erlang also has a case statement). This particular receive statement only matches for a single tuple, { From , { add , First , Second }}.

Tuples are fixed ordered lists of data and they are common in Erlang. The first element of this tuple is the pid of the sending process, bound to the variable From. This acts as a reply-to mailing address. The second element of this tuple is another tuple, consisting of an atom and the two terms to be added, First and Second. What is an atom? For the purposes of this article, let’s just think of atoms as constants that are never garbage collected.

After the incoming message is matched against this tuple pattern a tuple response message is sent back to the client process via the reply-to pid.

From ! {mathserver, First + Second}

This illustrates a third Erlang concurrency primitive: the send operator. Messaging can be challenging on most programming platforms: Erlang has it down to a single character. When we see “Pid ! Msg” in Erlang, it means “send Msg to Pid”. This allows us to sum both terms and send a response back to the math client with one line of code, fire and forget. The response is a tuple consisting of two elements, the mathserver atom and the sum.

Some of you might have laughed when you read the loop function: it ends with recursion. How reliable can this application be when it’s only a matter of time before the runtime produces the Erlang equivalent of a java.lang.StackOverflowError? You don’t have to worry about this. When the compiler encounters tail recursion it will optimize the Erlang bytecode so that the function can run indefinitely without consuming stack space.

Our last module function is the add function. This function is used to send and receive messages with the mathserver process. It uses many of the concepts and constructs previously covered: the send operator, tuples, the receive statement and pattern matching.

add(First, Second) ->

mathserver ! {self(), {add, First, Second}},

receive

{mathserver, Reply} -> Reply

end.

Look at the first statement. It creates a tuple message and asynchronously passes this to the mathserver process via the send operator.

mathserver ! {self(), {add, First, Second}}

Pay attention to two things here. First, to the right of the send operator we are not using the server pid. Instead we are sending the message to the mathserver process using the registered atom, mathserver. This is why we registered the server process back in the start function. Second, the self function has been introduced. The self function is a built-in function used to obtain the pid of the current process. For lack of a better analogy, think of the keyword “this” in Java. It is important the client sends its own pid as part of the message, otherwise the server would not know who to reply to. The add function ends with a receive statement used to match the reply message tuple sent by the server. When a message matching { mathserver , Reply } is pulled from the client mailbox, the second element of the message is returned. This completes the module.

-module(mathserver).

-export([start/0, add/2]).

start() ->

Pid = spawn(fun() -> loop() end),

register(mathserver, Pid).

loop() ->

receive

{From, {add, First, Second}} ->

From ! {mathserver, First + Second},

loop()

end.

add(First, Second) ->

mathserver ! {self(), {add, First, Second}},

receive

{mathserver, Reply} -> Reply

end.

Using the mathserver Module in the Erlang Emulator

Those of you familiar with BeanShell, irb or jirb will find yourselves at home with erl. Let’s run a few commands.

$ erl -name servernode -setcookie cookie

1> node().

‘servernode@byrned.thoughtworks.com’

2> pwd().

/work/tss/article

ok

3> ls().

mathserver.erl

ok

4> c(mathserver).

{ok,mathserver}

5> ls().

mathserver.beam mathserver.erl

6> mathserver:start().

true

7> mathserver:add(1,2).

3

What did that do? The shell command created an Erlang node called servernode. The built-in node function verifies this on line one. Lines two and three tell us the present working directory and what we have in it. Line four compiles and loads the mathserver module. The directory listing on line five reveals that the compile command has created a new file, mathserver.beam. Think of this as a .class file in Java. Line six starts the mathserver, spawning the server process. Finally we test our service with the add function.

It is now trivial to consume this service from any process on any node from any host as long as we specify the same cookie. On another machine, we can do this:

$ erl -name clientnode -setcookie cookie

1> node().

‘clientnode@dbyrne.net’

2> rpc:call(servernode@byrned.thoughtworks.com, mathserver, add, [1,2]).

3

In this shell we create a node named clientnode on the host dbyrne.net and use a function from the built-in rpc module. The call function takes four arguments: the fully qualified name of the target node, the name of the module containing the to-be-invoked function, the remote function name, and the arguments to be passed to the remote function.

Jinterface, Getting the Best of Both Worlds

Jinterface allows us to create a cluster of Erlang and/or Java nodes. It is distributed with many other useful libraries in the Open Telecom Platform. The OtpErlang.jar file has no dependencies and can be found under <ERLANG_INSTALL_DIR>/erlx.x.x/lib/jinterface-1.x/priv. All source code is open and licensed under the Erlang Public License, a child of the Mozilla Public License.

Remember when we remotely invoked the mathserver service from the clientnode node? Let’s do this from Java by porting the clientnode process to a ClientNode class.

OtpSelf cNode = new OtpSelf(“clientnode”, “cookie”);

OtpPeer sNode = new OtpPeer(“servernode@byrned.thoughtworks.com”);

OtpConnection connection = cNode.connect(sNode);

First we create an OtpSelf instance. The OtpSelf constructor takes two arguments: the node name and the cookie. Does this remind you of one of the command lines typed earlier? The node name and cookie values are identical.

$ erl -name clientnode -setcookie cookie

The second line of code creates a representation of the remote server node with an OtpPeer instance. The OtpPeer constructor takes the fully qualified node name of the server. Does this node name look familiar?

$ erl -name servernode -setcookie cookie

1> node().

‘servernode@byrned.thoughtworks.com’

Remember when we made a remote procedure call in Erlang?

> rpc:call(servernode@byrned.thoughtworks.com, mathserver, add, [1,2]).

Now that a connection has been established it is time to do this in Java.

OtpErlangObject[] args = new OtpErlangObject[]{

new OtpErlangLong(1), new OtpErlangLong(2)};

connection.sendRPC(“mathserver”, “add”, args);

OtpErlangLong sum = (OtpErlangLong) connection.receiveRPC();

assertEquals(3, sum.intValue());

The sendRPC method arguments are a one to one conceptual match with the rpc:call function arguments. We specify the name of the module containing the to-be-invoked function, the remote function name, and the arguments to be passed to the remote function. Finally, we use a static JUnit method to verify whether or not the Erlang server process is passing the correct message back to the ClientNode instance – the same way it did for the clientnode node. Here is the ClientNode class in its entirety.

import com.ericsson.otp.erlang.*;

public class ClientNode {

public static void main (String[] _args) throws Exception{

OtpSelf cNode = new OtpSelf(“clientnode”, “cookie”);

OtpPeer sNode = new OtpPeer(“servernode@byrned.thoughtworks.com”);

OtpConnection connection = cNode.connect(sNode);

OtpErlangObject[] args = new OtpErlangObject[]{

new OtpErlangLong(1), new OtpErlangLong(2)};

connection.sendRPC(“mathserver”, “add”, args);

OtpErlangLong sum = (OtpErlangLong) connection.receiveRPC();

assertEquals(3, sum.intValue());

}

}

Jinterface nodes can do more than just talk to Erlang nodes. They can communicate with each other as well. The servernode process can actually be reimplemented as a ServerNode class, allowing us to perform asynchronous messaging without a single line of Erlang. To do this the ServerNode must first tell the world it is “open for business”.

OtpSelf sNode = new OtpSelf(“servernode”, “cookie”);

sNode.publishPort();

OtpConnection connection = sNode.accept();

The ServerNode class begins by creating an OtpSelf instance – using the same node name and cookie as before. The node then publishes its port to the Erlang Port Mapper Daemon. This registers the node name and port, making it available to a remote client process. When the port is published it is important to immediately invoke the accept method. Forgetting to accept a connection after publishing the port would be the programmatic equivalent of false advertising. Once we’ve obtained a connection it is time to start processing messages.

OtpErlangTuple terms = (OtpErlangTuple) connection.receive();

OtpErlangLong first = (OtpErlangLong) terms.elementAt(0);

OtpErlangLong second = (OtpErlangLong) terms.elementAt(1);

long sum = first.longValue() + second.longValue();

connection.send(connection.peer().node(), new OtpErlangLong(sum));

The receive method of a Jinterface connection blocks until it receives a tuple from the ClientNode. Remember the receive statements back in Erlang mathserver module? Once a message is received the sum is calculated and sent back to the client. Here is the ServerNode in its entirety.

import com.ericsson.otp.erlang.*;

public class ServerNode {

public static void main (String[] _args) throws Exception{

OtpSelf sNode = new OtpSelf(“servernode”, “cookie”);

sNode.publishPort();

OtpConnection connection = sNode.accept();

while(true) try {

OtpErlangTuple terms = (OtpErlangTuple) connection.receive();

OtpErlangLong first = (OtpErlangLong) terms.elementAt(0);

OtpErlangLong second = (OtpErlangLong) terms.elementAt(1);

long sum = first.longValue() + second.longValue();

connection.send(connection.peer().node(),new OtpErlangLong(sum));

}catch(OtpErlangExit e) { break; }

sNode.unPublishPort();

connection.close();

}

}

Here is the ClientNode modified. The sendRPC method is no longer used to send an OtpErlangObject array. Instead the send method is used to send an OtpErlangTuple.

import com.ericsson.otp.erlang.*;

public class ClientNode {

public static void main (String[] _args) throws Exception{

OtpSelf cNode = new OtpSelf(“clientnode”, “cookie”);

OtpPeer sNode = new OtpPeer(“servernode@byrned.thoughtworks.com”);

OtpConnection connection = cNode.connect(sNode);

OtpErlangObject[] args = new OtpErlangObject[]{

new OtpErlangLong(1), new OtpErlangLong(2)};

connection.send(sNode.node(), new OtpErlangTuple(args));

OtpErlangLong received = (OtpErlangLong) connection.receive();

assertEquals(3, received.intValue());

}

}

Conclusion

Java and Erlang are not mutually exclusive, they complement each other. I personally have learned to embrace both because very few complex business problems can be modeled exclusively from an object oriented or functional paradigm. The solutions to these problems can be sequential or concurrent. Jinterface can cleanly divide (and conquer) a system into parts suitable for Java and parts suitable for Erlang.

References

Jinterface

Download Java

Download Erlang

Actor Model

About the Author

Dennis Byrne works for ThoughtWorks, a global consultancy with a focus on end-to-end agile software development of mission critical systems. Dennis is a committer and PMC member for Apache Myfaces. He is also a committer for JBoss JSFUnit and co-author “MyFaces and Facelets” (Apress publishing, Mar 2008).

JDK 5 in Practice Wednesday, Apr 30 2008 

By Cedric Beust

November 5, 2004

I have been writing JDK 5.0 code for over six months now, so I thought I would take some time to reflect on my experience and draw a few conclusions on the features that were introduced.

Enhanced for loop

The undisputed winner. I can’t even begin to describe how good it feels to use the new for loop everywhere (well, almost everywhere). I mentally cringe the few times when I am forced to use the old for loop, typically when I need the index or that I want the Iterator to be visible outside the loop.

The code is much more readable and feels less cluttered with noise (e.g. indices when you don’t need them or incrementation exposing the underlying implementation). This latter point was an unexpected benefit of the new loop, by the way. Imagine that you have:

String[] names = …;

for (String name : names) {

// …

}

and you decide that you want to change the type of names to a Collection. How do you modify your code?

List<String> names = …;

for (String name : names) {

// …

}

That’s right, just one line. It doesn’t get better than that.

Annotations

Obviously, I am partial to annotations since they are at the heart of TestNG but I am a firm believer that annotations are going to change the way we build software in Java. We have been relying for far too long on reflection hacks to introduce meta-data in our programs, and annotations are finally going to provide an excellent solution to this problem.

Also, I haven’t felt the need to use some of the predefined annotations such as @Override, so I haven’t formed an opinion on them yet.

It seems inescapable to me that in a couple of years, most of the Java code that we will be reading and writing will contain annotations.

Static imports

I hardly use them at all, except in my annotations type for Retention and Target. I am still not convinced that the original intent that motivated the addition of this feature (discourage the anti-pattern of implementing an interface to be able to reuse its constants without having to qualify them) justifies the introduction of a new language feature, but time will tell.

I guess that in some way, the use of an IDE in my day-to-day programming makes imports absolutely obsolete, so I can’t really get myself to feel strongly about this feature anyway.

Variable-length arguments

I haven’t had the need for this feature at all so far. It might come in handy once in a while but I’m really not convinced it warranted a change in the language.

Enums

While I definitely give Enums a theoretical nod of approval, I haven’t really converted my code to them yet, and I haven’t acquired the reflex to use them either. I believe that when I do, I’ll be happy with the result and it will make my code a tad more robust.

Generics

I left the best for the end… but since this entry is getting a bit long, I will save the Generics discussion for tomorrow.

Autoboxing

I have stayed away from autoboxing so far, probably because I have a vague feeling of losing control of the performance of my code. I don’t think it is justified, though, so autoboxing can come in handy and make your code a little bit more readable. I think I would encourage developers to flag their code when such autoboxing is happening, and I am pretty sure that IDE’s will soon be able to do the same.

Generics

Where to start?

Well, first of all, nobody can dispute that Generics are a solid concept that tends to improve the robustness of your code. The reason why they are so usually controversial regardless of the language is because of their implementation. And for having been a member of the C++ committee for many years , I can definitely vouch for the difficulty of getting them right.

In a nutshell, I have this to say about Java generics: my code feels more robust, but it’s harder to read.

So what’s the problem?

Redundancy.

First of all, I have always had a hard time with the redundancy introduced by the necessity of casting in general. For example, instead of writing:

Map accounts = new HashMap(); // no generics

Account a = (Account) accounts.get(“Cedric”);

why can’t I just write:

Map m = new HashMap(); // no generics

Account a = m.get(“Cedric”);

and let the compiler introduce a silent cast, since obviously, it’s an object of type Account that I am trying to retrieve from the Map?
Obviously, Generics don’t solve this problem entirely but they make a decent job at alleviating it somewhat. But they also make it worse in some other ways:

Map<String, List<Account>> accounts =

new HashMap<String, List<Account>>();

Ouch.
Not only is the code significantly harder to read, but it fails to obey the DRY principle (“Don’t repeat yourself”). What if I need to change the value type of this map from List<Account> Collection<Account>? I need to replace all these statements everywhere in my code. While IDE refactoring will help, it’s still an awful lot of code for a modification of this kind that hardly impacts the semantics of this code.

Admittedly, there is no nice way to avoid this syntax when you are creating a new object, but what I am driving at is that I think Generics would have been better off if typedefs had been introduced with them.

Or so I thought at first.

But after thinking about it more, I realized that typedefs were the wrong solution to the problem, because simply put, they don’t add anything to the use of a separate class to define your complex Generic type.

class AccountMap extends HashMap<String, List&lAccount>> {

}

Except for the fact that you need to extend an implementation (HashMap, and not Map, obviously), this solution is probably better than introducing typedef, which has its own quirks.

I haven’t gone to this trouble so far, but my recommendation would be: do it if you write the type more than three times (twice in the initialization and you use it more than once in your code).

Except for this little annoyance, I am quite happy with Generics overall and I particulary enjoy reading the TestNG Javadocs so nicely typed.

Conclusion

I am very happy with the new features of JDK 5.0 and I am quite proud to have had a chance to influence it with my participation in JSR 175 and JSR 201. Like all radical evolutions, not all of the new features will be popular with everyone, but as long as most developers find some of these features useful and that backward compatibility is preserved, I think JDK 5.0 is a very solid step toward more solid Java code.