I wanted to know if it was possible to use Spring MVC with a different JVM language than Java, e.g. Groovy or Scala. Or can Groovy only be run on Grails?
Also if it is possible, is this something which people try often, or do they just stick to the framework traditionally used?
Spring works perfectly well with scala because scala compiles to normal .class files which are Java-equivalent bytecode. I use Spring and scala all the time. It's even possible to use the Spring XML-extensibility to add support for scala-specific types, for example:
<bean class="my.scala.Class">
<property name="listProp">
<scala:list value-type="java.lang.Integer">
<value>1</value>
</scala:list>
</property>
</bean>
Sure, spring has excellent support for dynamic languages like Groovy. There is an entire chapter in the reference manual: http://static.springsource.org/spring/docs/2.5.6/reference/dynamic-language.html
As for scala; I tried doing this and it is possible. The problem is that JSP (or for that matter most templating languages supported by spring mvc) doesn't 'understand' scala collection types so I found myself converting between scala and java collections quite a lot. This should be better in Scala 2.8.0 but I haven't tested this myself.
Grails is implemented with Spring baked in, Grails 3 uses Spring-Boot. So that is definitely possible. You could also use Scala with Spring MVC. I don't know that you'd get the most mileage out of Scala with Spring MVC -- not a lot of opportunities to use Scala's functional programming features -- but there's nothing stopping you from trying it out.
I cannot speak for Scala, but I have personally used Spring with Groovy. Match made in heaven :)
Spring works very well with Scala, although Scala itself has features that mean you don't need
a dependency injection framework (such as Spring) in many cases.
Also, Scala isn't a dynamic language, it's a static language just as Java is. One of the primary goals of Scala was maximum interoperability with Java. This means that Scala compiles down to class files that look and feel just like Java objects, and can be seamlessly used as Java objects by external libraries and frameworks, such as Spring.
Well, what about writing the business logic in scala, so that the functional way scales well in multic core environments and let the rest handled by Spring and Hibernate. I think this is a pretty nice way to get the best of both worlds. Of course one can usw lift as a web app framework, but i think Spring is more actually mature and has more features. But the business logic is where the ball is rolling and so Scala and FP can handle this better than imperative java.
Right?
Your question should be classified:
groovy or scala compile to class and deployed
groovy not compile just deployed to tomcat
using traditional spring framework with a little groovy
using brand new framework to work with groovy e.g. grail
If you want using traditional spring framework e.g. spingmvc springcloud and want to add some groovy to implement business logic code, please use a new lib micro-mvc: https://github.com/jeffreyning/micro-mvc
This lib can scan interface as springbean and create a proxy to execute groovy.
Related
I am deciding if I should learn Groovy and Scala, and currently I am comparing web frameworks. I like the Groovy language a bit more, but Play! works with both Java and Scala. Another thing pointing me towards Play! is the tight CoffeeScript Integration. For collaboration purposes, I need my framework to be able to affectively communicate and interact with some sort of JavaScript. For my choice I have a few questions on the Grails frameworks.
Questions
Can Grails use Java, or just Groovy?
Does Grails have any tight JavaScript integration? I mean can the two technologies communicate at runtime?
The Eclipse Grails Project seems to be maintained by spring. Does this mean Groovy can use Spring?
I am still confused on which to learn. Hopefully the answers to these questions will help me decide which to learn.
All of this information is widely available on the internet, easily found using Google or your favorite search engine. That said, here are the answers to your questions:
Question: Can Grails use Java, or just Groovy?
Answer: Grails uses both. Groovy is a dynamic language which runs within the JVM and in a lot of ways extends Java. Grails uses both Java and Groovy. You can use both within your Grails project as well. This allows you to leverage the vast array of Java libraries available. Much like Grails itself does.
Question: Does Grails have any tight JavaScript integration? I mean can the two technologies communicate at runtime?
Answer: Any Javascript library can be used, and they can (if you make them) communicate at runtime. (Your question doesn't really make a lot of sense). In regards to coffeescript (which you mentioned in your question), there are plugins available that will compile coffeescript at build time for your Grails project.
Question: The Eclipse Grails Project seems to be maintained by spring. Does this mean Groovy can use Spring?
Answer: Grails is built upon Spring, so yes. You (and it) can use Spring. There are a great number of reasons to leverage the Spring framework within your Grails project, and with the Bean builder DSL it's fairly straight forward to do so.
Matt Raible has a great comparison of all the JVM frameworks. I suggest checking out Play and Grails within that comparison to see how they rank in the broader comparison...
http://www.slideshare.net/mraible/comparing-jvm-web-frameworks-february-2014
You can very well use Java in Grails framework. There are two options:
1. Grails has a separate source folder for Java - here you can use Java classes
2. You can also use Java code inside a Groovy classes
Grails uses Spring and Hibernate
Try both out. Choosing a web framework is a big decision and it's worth spending some time choosing.
Does Spring MVC now fully support using Scala as a language?
Are there any things that are problamatic or that take some special configuration/setup?
I personally just use spring mvc, IoC and then database helpers for hibernate (not really the security modules etc).
I am not sure if you are looking for any Scala specific features, but I have been using Spring MVC and Scala for over a year now. You can see my sample applications here and here that use Scala and Spring MVC.
That said, the integration of Scala and Spring framework could be better as the framework does not take advantage of Scala features out of the box. This is being addressed as part of the Spring Scala project which has reached release-candidate stage. There is a basic blog post explaining the project features and high level goals.
Actually I know good Java high level API and ORM for Apache Cassandra - Hector.
But can't find any native good solution for Scala. Anybody know any actual project with good quality, activity and ORM support for SuperColumns?
Phantom is actively developed and very well designed Scala DSL built on top of Datastax client.
Take a look at Scalandra a wrapper for Cassandra's Thrift API.
Besides scalandra there is also cascal and scromium
For example, Play-framework supports RESTful services like this: RESTful on Play! framework
How does this compare to something like Jax-RS Jersey implementation? Does a framework like Play run circles around Jersey because of all it's cool bells and whistles, and it does REST too?
Developer productivity is important, but so is a proper implementation. Perhaps using an MVC framework for REST only services is 'wrong'?
Note, only RESTful services, no UI components at all.
Even though it's not "wrong" to use an MVC framework for RESTful services, there are some pros and cons versus using a JAX-RS implementation.
(Disclaimer: I have only used Jersey and Play! for fun, and not on production-grade systems, so I have tailored my comments more generally to MVC vs. JAX-RS. Keep in mind that these are broad generalizations.)
MVC frameworks--at least the ones that are considered developer friendly and "slick"--typically save you from having to build a persistence layer (the model part). Most also simplify "routing" requests using either scaffolding via convention or some form of configuration. The downsides are that you have to conform to some conventions for your controllers and usually have to write a view for each resource (or build layers of abstractions to avoid rewriting the same code).
JAX-RS excels at defining the routing (using Java annotations) as well as eliminating any restrictions on the service class. In my experience, that has greatly reduced the amount of boilerplate code and developer overhead. Jersey and Apache CXF also handle the XML or JSON serialization using JAXB annotations, which eliminates the need to figure out the view in an MVC context. The downside here is that you have to figure out your own ORM or persistence layer, which could be good or bad depending on whether you're building on top of existing data or creating a greenfield system (or using something other than an JPA/RDBMS e.g. NoSQL data store).
My own personal comment: Play! is a really cool framework, but I'd choose CXF (or Jersey) over an MVC framework any day for building out a RESTful service. In my experience, this frees up the developer to focus on the logic needed for the service, and opens up options for different database approaches. Right tool for the right job.
As a rule of thumb: For Scala, use Play. For Java, use Jersey.
You can use Jersey/Scala and Play/Java; I've done both. It works. It isn't bad. But unless you have a particular reason to do that, I wouldn't mix ecosystems. Java and Scala are interoperable but they have different ecosystems, I would avoid adding Java-isms if you are using Scala or Scala-isms and dependencies if you are running straight Java.
Jersey and Play are generally close for REST services. Neither really has any killer features over the other.
Jersey defines URL mappings in annotations, Play defines them in a service wide route file. And they bundle or have varying quality of integration with different libraries for things like XML, JSON, database, testing, mocking, dependency injection libraries and app server deployment.
The Java world has JMS, Spring, JUnit, jdbi/hibernate/jpa, Jetty/Grizzly. The Scala world has Akka, specs2/ScalaTest, Anorm/slick. Jersey is a better fit for the first world, Scala for the second. You can definitely cross that, but it will be a little less elegant and might require more glue coding.
JAX-RS is a standard and implementations can be created by different vendors. Jersey is one such implementation. The other frameworks may make use of JAX-RS but are not standards. So it is not a one-to-one comparison.
I have never heard of Play before but it does look interesting, more akin to Rails and Django than Jersey. What I like about Jersey is that it can be integrated into existing Java web applications by simply adding the JARs and declaring some things in the web.xml. What I find confusing about Jersey and JAX-RS is the routing.
Play seems to make routing easier, however, correct me if I'm wrong, seems like it is an all-or-nothing framework and cannot be used alongside other servlets in the same web application.
Just thinking of implementing Guice in scala
Any sample code ?
Unless you specifically need Guice to add Scala to an existing Java-based project that uses framework, I'd advocate that you just use built-in language features instead.
Traits and implicits can give you all the Dependency Injection you'll need. You might also want to search online for the Cake pattern.
This post about DI in Scala will be able to help you to get going with Guice. See Using Google Guice topic.