The main developers include Steven Galarza ('Mystic Flow), Lumby, and Emperor (misanthropy).
Tons of compliance issues exist throughout the source. These issues, though fixable by rebuilding the dependency libraries, handicap developers from using developer JDK releases. Currently, the compliance issues exist all throughout XStream (requires you to construct an XStream object using a specific reflection unit).
Dementhium's wiring consists of perhaps the worst (anti-)design patterns to ever exist. First of all, the use of singletons destroys the testability of initialization, and also disables a proper multi-threaded implementation of the initialization. This is because singletons have dependencies on other mutable singletons, which must also be initialized before other singletons can themselves initialize. This is a horror, and introduces some of the scariest deployment I've ever seen. Why, you ask? Developers have no knowledge that, in order to initialize one component, another component also needs to be initialized. So, perhaps somebody wanted to reorder the initialization process to boot high-priority components first, they have no idea that those components rely on other global-state objects which were expected to be initialized before-hand. This issue can be fixed by enforcing singletons through non-JVM binds (static), and requiring, through parameters of the components of which that, on construction, also requires.
No documentation is present anywhere in Dementhium. This flanks developers from writing code "on fly", and restricts development to only those who have reviewed the source code of components who also know how to use the components. Without documentation, writing code is a pain... and many developers may actually chose to rewrite components instead of trying to understand [horrendous] peripheral already included in the source.
Dementhium posseses many, many system issues. These issues can be divided into a lot of categories, however, the amount of issues throughout Dementhium are immeasurable. As a result I will speak of a few.
First off, the whole one-thread-per-world idea is terrible, and I don't care about any contradicting opinions as they are rooted around turning blakeman8192 into some sort of demigod. If an executor service receives a large load it will block other loads from being processed. This is a terrible idea, especially when exercising time consuming components (like the ultra-slow pathfinding). This can be resolved by creating two services, one for main game logic (fast), and another for background logic which may be dropped (slow).
Next in line is the pointless "event-driven" (I would call it "idiot-driven") system from Hyperion. This is possibly the worst way to design a service system, and probably decreases flexibility for which services should have increased predominantly. What above all ticked me off was the whole "Message" encapsulation. What is the purpose to construct an object which only holds the data from a network event, and then deliver it to another component (more retarded global state) which it is then sent to an execution service by then creating yet another object along with implementation logic which only executes that messages data by shipping it to YET ANOTHER component which then queues the message to the associated player, and then another "event" is executed which processes those queued message requests by then shipping them to ANOTHER component which finally ships them to their true logic handler. Overhead much? A resolution is to use a much simpler system, which uses annotations to mark which handler implementations handle what operation codes, then, when the network receives a message it is shipped directly to a translation component, and then business logic executes.