This article is about the need of mhus-lib and a short history to explain. It also describes the different sections shortly (First of all it’s a library for the java VM).
The lib is called by my name because originally it was designed as a tool to solve problems I have in every project in the same way. The first version (in this time called mhu-lib) was a small set of static classes to convert data or to load simple information like the current host name.
In the next years the library was growing also solving more complex problems like how to handle different configurations in a common way. Handle POJOs and database access. It learned to serialize object into a RMDB and how to define forms in a generally way. Also a common logging framework I really love was implemented. That was version 2.
In version 3 all the things are becoming a more common and integrated touch. Package declarations changed and the library is now OSGi usable.
But why not using one of the common frameworks like apache-commons or spring? The answer is simple – for me – this library implements exactly what I need to develop and after some tries I know it’s more robust, faster and handier than the alternatives. This is really subjective but – for me – true. I have some basic rules to implement functions:
- Keep it simple: I don’t want to use complex stuff
- Keep it generic
- Robustness: It’s most important to think about when/where to handle exceptions
- Don’t reinvent the wheel
Currently there are the following sections:
MCast: Core tool to cast objects, separated in MDate parsing of date formats. The way of casting is mutable and can be extended dynamically by adding new casters.
MThread and MDeamonThread: Thread pool services
MEventHandler: To register listeners also as weak references if needed
MSystem: Core functions, e.g. to get the host name or to compare also nullable values (equals(a,b))
Small section to allow class loading. It supports single objects or to load default implementations for interfaces.
That’s a deprecated framework to load objects. The idea is to place pseudo static objects with the ability to be replaced. e.g. to replace the stdout stream for a part of the running VM. But it was not used often.
This section is used to load and provide dynamic mutable configurations.
A lot of different ways to load configuration files and provide it in the same interface into the application
Tools to work with console out/in e.g. to print coloured text in ANSI terminals.
Classes to use and in the same way provide JMS interfaces
Simple and generic logging. There are adapters for java logger, log4j and a direct console output. Goals also a absolute simple interface and a faster logging. Concatenate all outputs instead of creating a string even if the log entry is not logged, e.g. debug output: log.d(“interesting info”, nr1, nr2, nr3, exception)
Short parser and compiler to match inputs with a pattern. The pattern consists of regexpressions concatinated with operators like ‘and’, ‘or’ and ‘not’.
Parse and manipulate POJOs. There are different strategy implementations like ‘Function’ or ‘Attribute’ strategies. And also different filter options. Getter, Setter and Actions are automatically bound together.
Scheduler for non blocking timer or cron scheduling.
Classes to implement operations.
- MSingleton (system)
The only but mutable stateful singleton in the hole library
Form model and implementation using Vaadin Framework
Helper to work with J2EE, specially with web containers
Helper to work with JMS-Messaging
Commands and helpers to develop for the karaf OSGi framework. With a look for the mhu-lib sections
Helpers to develop liferay portlets
A huge framework to work with serialized objects. It’s similar to JPA but faster and easier to use.
Helper to develop standalone applications and servers
Helper for vaadin driven applications like tables and editors