I'm back to java after having an unsatisfying experience 2 years ago with Spring MVC, (this time i use the "play framework"), and it seems to confirm my intuition that the language itself is really just fine.
The problem lies more in bloated frameworks and corporate culture where everything needs to be standardized, regulated, and the purpose of a mandatory non-free training session.
Add to that the fact that every single topic is covered by at least 3 or 4 libraries, and you get a more complete view of the situation.
I kind of like that things are standardized/regulated in the Java space. If you're using anything close to industry standard tools and methodologies I can come in and be an effective member of your team faster. I know it can sometimes be more exciting to build something in a way no one else has ever built it before, but it's usually a bad business decision to do so.
This is one of the reasons why I still lament javascript. It seems like everyone and their mother is using a different framework to accomplish essentially the same task. The flavor of the week last exactly that long: a week.
How's Play! compare to Spring? I'm working on a bloated Spring whale (1.5M LoC, 485 Spring XML config files) and wondering if something like Play! can do it better, or if complexity is simply a beast that will inevitably turn any project into a turgid mass.
I ask since friends at Google will laugh at a bar if you even say "Spring," but I'm curious what else can do it all (Guice/Gin?). Perhaps nothing can and the trick is to simply have small, cohesive projects linked by common REST (et al) API's and to merely skirt complexity entirely. However, for workflow and state management, you'll inevitably need some common integration point.
I did a side project in Play! some time ago. While it was generally OK to use, Java in Play is definitely a second class citizen compared to Scala. Most documentation (which btw is sorely lacking) concerns how to do stuff with Scala and you'll have to figure out how to do the same in Java yourself.
Even worse, breaking backwards compatibility between even minor releases seems to be standard for this framework. So once you've finally managed to find some piece of documentation from some random source on the net (as again, the official documentation is pretty much a joke) you'll find that it doesn't work at all because it was written with Play! 2.0 in mind which is different from 2.1 which is different from 2.2 and so on.
Once you figure it out, it's a pretty nice framework. It's a shame so little attention seems to be paid to exposing that in a better fashion.
> Java in Play is definitely a second class citizen compared to Scala
Much agreed. I started a side project with a quick deadline with Java in Play and switched to Scala (even though I had to learn Scala) just because they played better together.
Play 1.2 is not-quite-as-supported as Play 2.x, but it doesn't have features that mostly make sense for Scala (e.g., text-based templates, not Scala-DSL ones)
I can strongly recommend Dropwizard for the plan. It is much less stuffy/enterprisy and you can easily split big apps into smaller services. It is some glue code on top of Jersey run in embedded mode Jetty (thus very little ops work needed).
Play Framework is also nice, but a bit too much opinionated! Meaning hard to make it do something in another way, which happens in real world big applications...
I've used Dropwizard but with my latest project I dropped it in favor of assembling libraries manually. There's nothing wrong with Dropwizard per se, it's biggest strength is that everything you need works out of the box, but it bundles some older versions of libraries (like jersey, jetty). I am now using latest Jersey, Jetty (embedded), Atmosphere, Ebean and RxJava with Kotlin. It wasn't that hard to setup everything manually and the benefit is that I can add anything I want. I work with Python and C# mostly and don't have that much experience with Java/JVM, but I really like this setup. I've also considered Play 2 with Java, but it didn't feel right to me and the documentation was out of date. Perhaps it's better with Scala, but I don't really want to learn an entire new language and ecosystem. Kotlin is similar to C# so for me it was a breeze to pick it up and I can transparently use any Java library with Kotlin by just importing it.
Jetty is up to date, but Jersey is old yes. But the new jersey is also a bit problematic, more stuffy and slow (from the benchmarks of others, I haven't done it myself). But the good thing is, there is a big and passionate contributor community around dropwizard (check their github/google groups) and this means if the new versions of libraries are worth updating, they get in pretty quickly.
Spring is a huge umbrella project that contains many parts, some good, some not so good. Guice or picocontainer work well, but you can achieve the same effect by using spring's Java configuration and avoiding silly things (AOP, shudder), and that way you can migrate existing spring XML piece by piece.
If you're writing an actual webapp (i.e. something that outputs html) then I highly recommend Wicket; it's the most beautiful framework I've ever used, in any language. If it's just REST APIs I can't really recommend anything - by the time I started writing those I'd switched to Scala (in which Spray is wonderful).
I'm with you that Spring has ALOT of parts. At my company they allowed us to use some parts of Spring and not others. Our stack was Spring MVC, with Apache Tiles, serving JSPs with some JQuery in there all wrapped up with Spring Security. It was much better than what we had before, JSF and ICEFaces and ADF. JSF frustrates me to no end.
Now we're moving towards a more modern stack. Using Jersey for REST is nice. It does make me enjoy Java again. You annotate resources in a Spring-like way, security was easy to implement. On the front-end we use a client side JavaScript Framework, JMVC (CanJS, EJS, etc). JMVC doesn't have as much traction as other frameworks, like Angular or Ember, but it is stable and covers what we need.
But when I go home, I try to stay away from Java. It's mostly Python (Flask, Tornado, Twisted) or lately some Node (Express) on the backend and Ember on the front. It's psychological. I program at work for work and at home to have fun. For me it just feels easier and more fun to stream code in Python.
For rest services in java I really recommend Dropwizard. Wraps a bunch of great libraries together with just enough glue to make your development easy. Really great support for metrics.
I while ago I had to choose a JVM based MVC framework to work with and originally I was looking at Spring. Needless to say it's a Mount Everest of frameworks, so by looking for alternatives I've stumbled upon Play. I decided to go the whole way and use Scala with it. Never looked back since. Typesafe stack offered me a rock solid Scala/Play/Akka/Slick stack with type safety, scalability, immutability, concurency that few others have (if any).
Modern Spring is quite nice, and after having tried Play, I go back to Spring MVC, but use Spring-Boot with Jetty was the embedded container.
Its much like Dropwizard, but better integrated with Spring if that is what you are used to or like.
No XML, and I can produce a usable web API with a minimal amount of boiler plate (its all wrapped up in Spring boot, much like Play wraps up a lot of stuff for you).
Yes, Spring Boot is pretty cool. Not a bit of xml in sight, unless you want it, of course. And you have the choice of deploying with an embedded Tomcat or as a more traditional war.
I think a lot of "big Java" haters haven't looked at Spring or JEE (which has seen similar massive improvements) in the last several years.
Not sure what version of Spring you are using, but the newer versions allow you to annotate your way out of the need to have so many XML files.
Code bloat is a different beast. Unless the company decides to refactor and redesign the whole thing, you probably have to live with it, like the rest of us.
Note that Play is only really comparable to Spring MVC, it's not a general-purpose dependency-injection framework. In the DI space Guice is more of a competitor to Spring.
Play is simpler compared to Spring but idiomatic Play code also requires you to learn reactive programming, something you probably won't do in Spring MVC.
I was just recently trying to decide between "new" Spring MVC, Dropwizard, and Play.
Spring now has a bunch of slick-looking guides and tutorials. But then I looked at the actual contents of their tutorial project, and it just turned me off. For an "example" REST project, they had over 50 classes not including tests: https://github.com/spring-guides/tut-rest/tree/master/6/comp... , with many being "event" classes of some sort. I mean, WTF, is this really the "idiomatic" way to build Spring REST/MVC projects nowadays? I'm trying Dropwizard for now.
Been there done that. 3.5 years of Play 1, but they decided to rewrite it in Scala and I left in anger.
Nearly one year now of servlet dev, trying nearly anything I can get my hands on. Most I have been satisfied with is Restlet for service development, otherwise nothing even comes close to Play 1.
Finally decided to harden up and learn Scala. I have set my prejudices aside and after a month, I can safely say I am a _write_only_ Scala developer. I still can't read much of the fancy code in the wild, but for my immediate needs, gluing java libraries together, it's a far superior language to Java.
My opinionated guide to developing modern Java is: get TypeSafe Activator and learn Scala.
I actually started learning Scala: completed Odersky's Coursera class and developed a Play 2 project in Scala. Overall I like it, but reading others' code is often frustrating, shorthand shortcuts in language are still kinda alien looking, and even figuring how to handle simple things like multi-file upload with Play's controllers, I feel I don't quite understand what the hell is going on underneath all that magical functional code that I myself wrote by assembling bits and pieces from elsewhere.
And then I watch stuff like Paul Phillips presentations [http://www.youtube.com/watch?v=4jh94gowim0] and I just don't know whether continuing to invest my time in Scala is a wise decision long-term.
I'll probably try Clojure at some point, but for production-grade projects I will do Java for now. I feel the most frustrating thing about tech is having to place bets constantly on what to invest your time learning. It's eerily similar to investing in stocks. You never know what's going to live or die. And I'm saying this as a former Delphi developer with multi-year experience. :)
I started Scala from cold as it were without having ever done Java. I found myself having to read Scala code (source for things like Lift) 'backwards' to understand it. I read the body of functions from top to bottom but lines from right to left as maps/flatmaps make much more sense to me when picked apart that way. Maybe this is common/standard, not sure.
I'm using Dropwizard and it was easy enough for me - former .NET developer to get things done quickly. That said if I was starting today long term project I would go with Dartlang (yes they'are server side as well)
I'm using Dropwizard for the same reason. It is dead simple and gets me going out of the box. You should also give Grails a try if you plan on having a view layer
Yes it is just a binding between Jersey and templating engines (they maintain two of them: mustache.java and freemarker. I strongly recommend freemarker, since it is more complete in UI related transformations. This way it lets your Model layer to stay clean. But if you need something exotic, you can bind to your templating engine of choice easily)
I think that to a certain extent, the standard library also encourages this culture, since that's the most prominent and arguably widely used piece of software that's written in Java and it will be used as an example of "good" code.
The continuing notion that CS classes teach objects first (I've heard recommendations that it be before even conditionals and loops, shockingly enough) I think is also a contributing factor: "When all you have are classes, everything turns into an object."
But as things like Java4K suggest, the bloat may not be inherent in the language itself; it's certainly possible to write concise, efficient Java code.
How ironic... I was an early adopter of Spring, when it was all about simple "enterprise development without J2EE". So, given enough time, does bloat follow success and does it become inevitable?
Add to that the fact that every single topic is covered by at least 3 or 4 libraries, and you get a more complete view of the situation.