If there’s one thing you need to know about JBoss AS 7 is that it’s extremely fast. You definetly need to have a look at it if you need a container for your next java project.

The EE 6 demo Kabir did was mainly a combination of a few of the quickstarts, so he could introduce the concepts gradually using the same application. The quickstarts can be found here and some of them are explained in much more detail at this page in the “Getting Started Developing Applications Guide”.

The archetype for creating the html 5 stuff can be found here. There is a link to it from the aerogear project
Meeting was sponsored by Betfair Romania.

[Originally hosted at: www.scientixs.com]

If you ever found yourself in the situation of using a FSM on your design you have probably started to write classes for every state which implemented the same interface. A good design might have been:

interface State { }
class State_1 implements State {}
class State_2 implements State {}
...

And you probably had a class that managed these states and the transitions between them, and another that implemented the Context of the FSM (the input band strip) and another interface for the starting states and one more for the end states and so forth. A lot of classes spread out in a lot of files that makes you to quickly lose track of them.

There is another way: using enums.

Enums are essentially list of classes, and each member of the enum may have a different implementation. suppose we have the following state machine that we want to implement:

Init -('a')-> A
Init -(else)-> Fail
A -('b')-> B
A -('c')-> C
A -('a')-> A
A -('')-> End
A -(else)-> Fail
B -('c')-> C
B -('b')-> B
B -('')-> End
B -(else)-> Fail
C -('c')-> C
C -('')-> End
C -(else)-> Fail

This FSM will validate the following regexp: ^(a+)(b*)(c*)$. We can write the states as elements of the enum State as follows:

interface State {
    public State next();
}

class Input {
    private String input;
    private int current;
    public Input(String input) {this.input = input;}
    char read() { return input.charAt(current++); }
}
 
enum States implements State {
    Init {
        @Override
        public State next(Input word) {
            switch(word.read()) {
                case 'a': return A;
                default: return Fail;
            }
        }
    },
    A {
        @Override
        public State next(Input word) {
            switch(word.read()) {
                case 'a': return A;
                case 'b': return B;
                case 'c': return C;
                case '': return null;
                default: return Fail;
            }
        }
    },
    B {
        @Override
        public State next(Input word) {
            switch(word.read()) {
                case 'b': return B;
                case 'c': return C;
                case '': return null;
                default: return Fail;
            }
        }
    },
    C {
        @Override
        public State next(Input word) {
            switch(word.read()) {
                case 'c': return C;
                case '': return null;
                default: return Fail;
            }
        }
    },
    Fail {
        @Override
        public State next(Input word) {
               return Fail;
        }
    };
 
    public abstract State next(Input word);
}

What we’ve done is we’ve defined the transitions of every state inside each enum. Each transition returns a new state and as such we can cycle through them more efficiently:

State s;
Input in = new Input("aabbbc");
for(s = States.Init; s != null || s != States.Fail; s = s.next(in)) {}
 
if(s == null) {System.out.printlin("Valid!");}
else {System.out.println("Failed");}

At this point, we have either validated the string or failed. It is a simple and elegant design.

We could further improve the implementation by separating the final states from the main ones as to simplify the exit condition of the traversal. We will define another interface called FinalState and a second enum that would contain the desired exit states (changing also the States enum accordingly):

interface FinalState extends State {}
enum FinalStates implements FinalState {
    Fail {
        @Override
        public State next(Input word) {
               return Fail;
        }
    },
    Ok {
        @Override
        public State next(Input word) {
               return End;
        }
    }
}

As such, the traversal will be somewhat simplified:

for(s = States.Init; !(s instanceof FinalState); s = s.next(in)) {}
switch(s) {
    case Fail: System.out.printlin("Valid!"); break;
    case Ok: System.out.println("Failed"); break;
    default: System.out.println("Undefined"); break;
}

The advantage is that (besides a simpler traversal) we could specify more than two final states. Most of the times, a FSM will have more than one exit point so this last improvement is recommended for the long-term. You can also place all these enums and interfaces inside the same source file and have the whole logic in one place rather than surf through multiple tabs in order to understand how the flow works.

As a conclusion, using enums makes for a more compact and meaningful implementation of a FSM. You have all the logic in one file and all traversal is painless. You will also have a much more easier debugging experience since the name of the states in which you’ve translated will appear in the debugger ( the variable s will change its value accordingly, bearing the name of the new state) rather have to figure out what class you have just jumped to. All in all I think it’s a good technique to have in mind.

[Originally hosted at: www.scientixs.com]

Google Protocol Buffers (shortened protobuf) is data (de)serialization with good speed, size and cross-platform support (it supports Java, C++ and Python out of the box). It can also handle different versions of the same message (as in: old and new code running side-by-side) if its rules are followed. There is one cornercase which it doesn’t handle well: parsing of arbitrary messages (one example where you might need this would be a logging daemon which sits on your network and logs all the messages going by for later debugging). The reason for this is that in protobuf data travels without its metadata (ie. the description of the message format – number of fields, their types, etc) and it supposes that the metadata is present on both ends (it can be different versions of the metadata though).

To parse an arbitrary message you need access to its metadata, there is no way around it. What I would like to present in this post is a simplification of the usual solution (generating a “.desc” file – which involves). The solution is completely runtime and no extra build steps are needed after the initial setup. This is how it works:

We set up a generic “Metadata” structure. This is the only thing which is needed to be shared between different communicating parties:

package tutorial;

option java_package = "com.example.protoctest";
option java_outer_classname = "MetadataProtos";

message Metadata {
  required bytes field_descriptor = 1;
  optional int32 field_descriptor_idx = 2;

  repeated Metadata dependencies = 3;
}

Next, we populate this structure for the message we want to send. You can look at the actual code for details. The most important aspect is that this needs to be done recursively since protobuf allows for the nesting of types (although not for inheritance).

Now, we can ship over the metadata and data to the client. Probably each communication channel/topic has a limited set of message types it can contain, and as such you won’t need to waste bandwidth with the metadata before or after each message (you can send it once per channel, or maybe every time a new client joins or the message version changes, etc).

At the client you can deserialize the metadata and using it together with DynamicMessage reconstruct the contents of the message. Again, you can see the full details in the code.

Hope this helps somebody facing a similar need! The code can also be used as a reference for how to use the maven-protoc plugin. Finally a word of caution: make sure that your proto compiler (protoc) and the runtime libraries used match as closely as possible in version (for example protc 2.4.0 and protobuf-java 2.4.1 is ok, but 2.2.0 wouldn’t), otherwise you will get some really hard to track down compile time / runtime errors.