Gemini is a Java Servlet-based framework that we have developed and maintained internally for the past 13+ years. We do web development and consulting, and today we happily use a variety of platforms and frameworks. But as you might imagine, in 2000 the selection of web frameworks was, to put it mildly, disappointing. In the Java space, the predominant option in that era was Struts, which did not appeal to us. We wanted something simpler and ended up building what we wanted.
Gemini has to-date been used on projects that we initiate, so the limited and informal documentation is sufficient. Given the limited audience, we've enjoyed the flexibility to add and remove components at will. For example, we wanted to replace JSP, so there was a brief discussion, and we decided to adopt Mustache. The friction level is very low because the need to support legacy applications is narrow compared to an open source framework, something with a large user base.
When we started this effort to compare the performance of web application frameworks, the first implementation of the tests that we wrote was in Gemini. After all, we wanted to collect this information to give us data to reference when speaking with clients about their projects' technical options. For example, we wanted to be able to better answer a start-up client's questions about scale pain if they are choosing between, say, PHP, Ruby, and Java.
When we decided to share our findings, we debated whether to include Gemini in the results, knowing that it was perhaps unfair to include a closed-source framework that no readers would recognize. But on the other hand, we wanted to be able to reference the charts in our ongoing discussions. Plus, admittedly, we were proud to see it do relatively well. So we left it in and simply ask that readers either ignore it or consider it a stand-in for a similar small-audience Java framework.
We have been asked whether this frameworks benchmarks project was a prelude to open sourcing Gemini. It was not. For a few years now, we've been on the fence about open sourcing it, but have refrained because we do not feel we have the personnel bandwidth necessary to give an open source project the attention it deserves. Nevertheless, questions such as yours are giving us reason to reconsider. If we did so, we still don’t have the time to shepherd it and to answer support questions if people try it out. The chief value in open sourcing might be fairness from the context of the benchmarks project.
Some high-level architectural notes and features:
- MVC using a custom entities and relationships data model, request handlers for control, and Mustache for views. Views are only recently Mustache, they were formerly JSP.
- Custom lightweight ORM with optional in-memory caching. Object construction uses ReflectASM. Entities and relationships are modeled but traversal of relationships is handled by applications (there is no higher-level query language).
- Custom JDBC connection pool.
- Custom cluster (built using KryoNet) for distributed cache and other inter-server communications.
- Performance monitor and administrative notifications.
- Security features: standard users and groups model; bcrypt password hashing; CSRF countermeasures.
- Starter site administration user interface: user and group management; cache management; configuration management; performance monitor view; WebSocket log monitoring.
- Miscellaneous: simple auditing; a task scheduler; logging; a custom JavaScript writer (soon to be deprecated in favor of Jackson); a request simulation interface (allowing applications to be used or controlled without an HTTP layer); outbound e-mail templates and delivery; inbound e-mail handling; form validator library; internationalization/locale support; WebSocket support.
- Notable dependencies: Guava; Java Mustache; Kryo/KryoNet; ReflectASM; Trove primitive collections.
- Design-wise, we’ve attempted to ensure that requests are handled with as little need for locking and synchronization as possible. We make fairly heavy use of immutable data structures and Java’s concurrent data structures.