4 ms·
Hi gog, I'm sorry you spent time trying to get started with Gemini, because it's our internal framework that isn't released yet. That would have been frustrati
by krg 13y ago
Hi gog,
I'm sorry you spent time trying to get started with Gemini, because it's our internal framework that isn't released yet. That would have been frustrating for you!
From our "Motivations" section: http://www.techempower.com/benchmarks/#section=motivation http://www.techempower.com/benchmarks/#section=motivation "Why include this Gemini framework I've never heard of?" We have included our in-house Java web framework, Gemini, in our tests. We've done so because it's of interest to us. You can consider it a stand-in for any relatively lightweight minimal-locking Java framework. While we're proud of how it performs among the well-established field, this exercise is not about Gemini. We routinely use other frameworks on client projects and we want this data to inform our recommendations for new projects.
- continuations 13y agoIn previous rounds there were some discussions that you were considering open sourcing Gemini. Is that still on the table or have you decided against it?
- krg 13y agoIt is still on the table, but we haven't made much internal progress on this yet. Hopefully we'll get there before too long.
- gog 13y agoThank you, now I understand why I couldn't find anything useful on this page http://www.eclipse.org/gemini/web/ http://www.eclipse.org/gemini/web/ :) Nevertheless I am still looking for good resources on getting started with Java (ecosystem wise, not the language itself).
- columbo 13y agoHave you considered starting with Grails? It's a much easier jump into the "java-ish" world. The main benefit is you can choose to run a grails application and rely on java jars for when you need performance boosts.
- wasd 13y agoWe've been using Groovy internally for a few years for prototyping and experimentation. I thought about slowly introducing Grails as an alternative to Spring for some projects. My experience was that it vaguely reminded me of Rails but needed a lot more polish. I had a huge issue trying to chase down archaic stacktraces and found that there is little developer momentum pushing it forward. I usually found myself googling and reading random blogs to figure out simple things I couldn't infer from the docs. Where as Rails magically makes things work, I found that a lot of times Grails made things magically not work. I wouldn't personally suggest it for anything customer facing.
- vorg 13y agoYou could use JRuby and Rails if you need the JVM. Groovy's OK for wraparounds testing and/or running Java classes, what it was originally intended for, bringing closures and terser list/map syntax (altho JRuby et al have those too). It's all rather slooooow though. Grails uses Groovy's MOP which was added later, but I don't use them much. I toyed with Groovy's interceptors and categories when they were added, even wrote notes on them, but they broke in the upgrade from 1.5 to 1.6. There's a lot of such cruft in Groovy which just lapses from version to version through lack of use and support. They brought in AST transforms to get programmers to extend Groovy's functionality, but when they do, the Groovy managers wil swipe the code and pass it off as their own in the next version of Groovy (e.g. Groovy++ written by Alex Tkachman was cloned as the static compilation in Groovy 2.0 and the static traits in the upcoming Groovy 2.2). tldr... Use grOOvy for quickies handling Java classes, and for Grails where it's required, but look at a serious programming language for anything larger.
- wasd 13y agoI would much prefer using JRuby/Rails but we have a bus factor of 1 with Ruby :(.