1. There was a history of heavy-weight, overly verbose frameworks. The early frameworks were over-engineered and hard to use. Lightweight frameworks in dynamic languages (Rails, django) thus took off when you they showed how you could write a blog app in fifteen minutes using only a few dozen lines of code.
2. Using non-Java JVM languages seems to always create as many problems as it solves, in my experience. First, you do not get access to any libraries with C-bindings. So as your project gets going, the probability increases that some library you want to include won't work. Also, there are all sorts of micro-frictions. Debugging support not quite working. Types not matching between Java numbers and python numbers when doing comparisons. Etc. It all adds up. If you use Kotlin, then a lot of code samples you find on stackoverflow will have to be manually converted.
3. If you go pure Java, the type system can be a pain in the neck when you are doing rapid development. Something as simple as getting a row out of the database with date field, publishing it as JSON, then getting posted back an updated version from JSON, requires a bunch of conversions and annotations to make the types all get matched correctly. Writing any sort of time-saving meta code requires a really strong knowledge of how generics, annotations, and reflection works, or else you will be beating your head against the wall.
4. Restart times are longer, and there is no REPL, so rapid iteration is a little slower.
5. I still don't think there is a web framework that is as easy to use as Rails/Django. I don't think this is the fault of the language though, and I have something in the works myself on this front...
For me (5) is the major reason. Web development with Rails/Django is so much easier and smooth compared to that of any Java/JVM based frameworks, it doesn't make sense to use the Java/JVM ones. Even a Ruby/Python novice can pick up and run with Rails/Django. You will end up building a robust, secure solution following well documented best practices and leveraging abundant 3rd party library ecosystem.
I think Play Framework is trying to achieve such usability, but I don't think it's there yet.
Play probably is the JVM world's best answer to Rails/Django, but it's neither as complete nor as frictionless. Source: I use both Rails and Play at my day job.
There are several pretty light-weight ways to make both action- and API-oriented back ends on the JVM now, even in Java. (Although I prefer different JVM languages.)
2. JNI debug is a bit of pain probably. But Java/Groovy/etc much easier to debug, compared to, say, Python
3. IMO there're no much reason to use pure Java in webdev. Only if you have well defined project, maybe already written in JVM language, that you want to optimize
4. Depends on language. Clojure have one. Groovy/Grails too.
I was never managed to debug python code :( Maybe i'm doing something wrong. Never mind, I didn't want to offend python, it's only language I like besides jvm languages.
On other hand on JVM you don't even need such line, all works out of box, w/o code modification, never had any problem. At least with java and groovy
2. stacktraces != debug. I don't actually see any difference with java stacktrace (only that it contains groovy classes, but it's still exactly same format). I mean tools for debug, like debug in IDE (look at Intellij IDEA, very powerful in debug), or JMX, take a look at VisualVM and profiling tools. There're many different tools. It's not just stacktrace.
5. Agree, not so popular that plain Spring maybe. But still, we're talking about features, right? not amount of projects on prod. Grails is pretty comparable to Rails/Django, in terms of features. Also, version 3 is too new, it requires to rewrite a lot of stuff to migrate. It takes time.
2. Using non-Java JVM languages seems to always create as many problems as it solves, in my experience. First, you do not get access to any libraries with C-bindings. So as your project gets going, the probability increases that some library you want to include won't work. Also, there are all sorts of micro-frictions. Debugging support not quite working. Types not matching between Java numbers and python numbers when doing comparisons. Etc. It all adds up. If you use Kotlin, then a lot of code samples you find on stackoverflow will have to be manually converted.
3. If you go pure Java, the type system can be a pain in the neck when you are doing rapid development. Something as simple as getting a row out of the database with date field, publishing it as JSON, then getting posted back an updated version from JSON, requires a bunch of conversions and annotations to make the types all get matched correctly. Writing any sort of time-saving meta code requires a really strong knowledge of how generics, annotations, and reflection works, or else you will be beating your head against the wall.
4. Restart times are longer, and there is no REPL, so rapid iteration is a little slower.
5. I still don't think there is a web framework that is as easy to use as Rails/Django. I don't think this is the fault of the language though, and I have something in the works myself on this front...