Container, the future?

It’s The Future
Hey, my boss said to talk to you – I hear you know a lot about web apps?-Yeah, I’m more of a distributed systems guy now. I’m just back from ContainerCamp and Gluecon and I’m going to Dockercon next week. Really excited about the way the industry is moving – making everything simpler and more reliable. It’s the future!

end() is a grey area in, if there is one, Camel's best practice. I can't find any articles discuss on it. However, I still prefer stick with it rather than ignore it is because:

• The use of .end() is to indicate where a part, a block route code is ended. Like scope in other programming languages, in this case route scope, .end() is to let Camel know where the code ends and belongs to.

• .end() in Camel DSL is matching Camel Routes defined in XML. In XML, a opening tag MUST have a matched closing tag.

• Symmetry in Camel DSL syntax. Like bracket matching, the code looks better symmetrically with .end().

• Last and the most important, play safe. Camel has a few weird behaviours. Don't want to strange behaviours, caught fire at runtime in production just because .end() is ignored and left any chance for code vulnerability is being exploited.

A Utility class is just a place holder of related functions and is not meant to be instantiated or subclassed.

A Utility class has the functions which is independent of object instances. Those functions are kind of aggregate functions. They only depend on parameters for return values. They are not associated with class variables of utility class.

So most Utility classes functions are kept static. As a result, Utility classes are ideally classes with all the static methods. So calling these methods don't need to instantiate this class.

So it's better a Utility class should be final with static methods and private constructor. This is not necessary, but it is convenient.

So preventing instantiation and extension sends a correct message to the users using the Utility class.